Comments (13)
Doing a bit of research here this morning, and it seems OAuth 2.0 is in pretty heavy use (Google, Flickr, LinkedIn, Twitter, etc...)
Certainly there should be some flexibility -- some implementations won't require authentication for certain pieces of data, for example, and we probably should be ok with implementations using other methods. That said, it might be a good idea to build in support for OAuth 2.0, seeing as it's so popular. Thoughts?
from osdi-docs.
When we implement we definitely want to go OAuth 2.0 but I'm OK leaving it out of the spec. OAuth 2 has some drawbacks: http://news.cnet.com/8301-1023_3-57481166-93/oauth-2.0-leader-resigns-says-standard-is-bad/ http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
Generally though it's safe as long as you implement callback security and you must use SSL.
from osdi-docs.
Isn't OAuth an authorization framework more than an authentication framework? I don't think we need an authorization system so much as an authentication system.
For authentication, the options are usually:
- API Keys
- Basic username/password over SSL
- Client certificates
I actually think we may want to strongly suggest an API-key based authentication framework to aid in interoperability. It would be great if accessing an API always required just two pieces of data, the URI endpoint and an API key.
I understand that solution may not be sufficient for some organizations who would rather use client certificates for additional security though.
from osdi-docs.
I guess I'm not sure I completely understand the distinction. With oAuth2, you have the authorization piece, but then you get an auth token to append to your requests, so it impacts the URI request structure, at least as I understand it. API keys also do that, but they don't seem suitable for, say, javascript implementations where you may have to secure the data but can't secure the key because it's client side. Hence the oAuth solution.
from osdi-docs.
On the general auth issue, I think our best hope is to describe it as a framework, where server implementors choose from a set of specific and unspecified mechanisms. It would be great if we can agree on a minimum support level (say API key or HTTP basic auth), but in my experience this is a rarity. A SHOULD may be possible, but there are many potential implementers that are not currently in our committee.
Beyond stating the framework, we should lay out conventions for how some mechanisms are applied to OSDI if there are multiple ways. Eg, where does the API key go?
I fished out some text from a very early version of OSDI (before we moved to github) on this:
Security
Encryption
Providers shall support secure HTTP connections using TLS. TLS 1.0, which shall be implemented, is specified in [RFC2246], and the TLS 1.1 and TLS 1.2 should be implemented as specified in [RFC4346] and [RFC5246], respectively.
Providers may support non-secure HTTP connections.
Authentication
Clients and Providers may use a variety of mechanisms to authenticate and authorize operations. The specification does not currently require supporting a specific method. However, there are many choices which should work with this specification.
• Cookie Based Authentication
• HTTP Basic
• HTTP Digest
• Token Based Authentication
• OAuth
• OpenID
Future versions of this specifications might get more specific in its security requirements.
from osdi-docs.
I think it would be beneficial to standardize one or two of the methods, even if that method isn't being used by all implementations. For example, we can say if you're using a simple API token, then it needs to be appended as an HTTP header with the key "osdi-api-token".
Without some sort of authentication standards in place it would be much more difficult to write a client that could talk to all servers. We'd end up trying to support a ton of configurations ala Microsoft's WCF.
It would be great if I could build the following dialog into my OSDI consuming application and have it just work.
from osdi-docs.
Here's a Stack Overflow post that talks about Facebook headers. Basically there's an option to put the API key in the URL or HTTP headers. I'm not sure why we'd ever want them in the URL:
from osdi-docs.
I think the main reason people put these things in URLs (or POST data) is
for web developer simplicity. Modifying/parsing of URL query params is
well understood and consistent.
Making the right programming calls to insert and parse http headers is less
so.
On Thu, Nov 14, 2013 at 3:30 PM, Brian Vallelunga
[email protected]:
Here's a Stack Overflow post that talks about Facebook headers. Basically
there's an option to put the API key in the URL or HTTP headers. I'm not
sure why we'd ever want them in the URL:—
Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/48#issuecomment-28519922
.
from osdi-docs.
I did some further research into OAuth 2.0 and found some interesting things. One of the main changes to the 2.0 version was the removal of the cryptographic signing of all requests. This makes it easier to implement, but when used with the simpler two-legged version, provides no actual benefit over a simple API key. This is one of the reasons the main author of the spec resigned from his post and took his name off of the standard.
from osdi-docs.
Which is probably fine, right?
I mean, to me, the advantages of oAuth 2.0 would be that we can support one standard way of authenticating for all situations -- two legged for server to server, and normal when we need more security (like individuals authorizing apps, or client side implementations).
But this is all assuming we actually decide to support or recommend something. If we do, I'd argue for going with one method (oAuth 2.0) over more than one (oAuth or api key, depending on your situation).
from osdi-docs.
BTW, pull request for basic security/authentication section available for review here:
https://github.com/wufm/osdi-docs/pull/54
from osdi-docs.
I'm fine with oAuth 2.0 in theory, but I haven't actually tried implementing it yet to know for sure. An API key and HTTP Basic auth are so trivially easy to implement, I wouldn't want to discard them so quickly. I think both of these are post-beta anyway as we have more pressing matters right now.
from osdi-docs.
close per 11/21 approval
from osdi-docs.
Related Issues (20)
- Machine readable spec HOT 3
- We do not have a "general concepts document" with "more information about identifiers" HOT 1
- Advocacy Campaign Fields: change "target_list" to "targets" HOT 2
- Specify location based searches HOT 6
- Events should support more than one organizer HOT 4
- Autoresponse Trigger Params HOT 13
- Field for 501c[3|4] safety HOT 1
- OSDI Organizations Resource HOT 1
- RFC on extending Person resource for Organization use cases HOT 10
- helper action functions: Improper use of "improper subset"
- No open source license HOT 10
- spec is hand-wavey on how to use $expand to include additional properties/resources HOT 1
- Location searches are underspecified in ODATA HOT 4
- Cost efficient mappings to underlying APIs HOT 5
- TypeScript Definitions HOT 5
- @osdi scope on NPM HOT 7
- API Limit Metrics HOT 1
- Discovering Available Custom Fields HOT 1
- OSDI sandbox setup not working HOT 3
- Action Network's Coercion (was Response to PUT on api.opensupporter.org) HOT 18
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osdi-docs.