Authentication?

[j-ro]

Does the group plan on publishing any standards on how to authenticate users?

It could certainly be left open as well, but if there are plans on supporting certain authentication types officially would be good to get some guidance on that.

[j-ro]

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?

[tobowers]

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.

[BrianVallelunga]

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.

[j-ro]

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.

[joshco]

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.

[BrianVallelunga]

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.

[BrianVallelunga]

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:

http://stackoverflow.com/questions/16526211/how-should-a-client-pass-a-facebook-access-token-to-the-server

[joshco]

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 notifications@github.comwrote:

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:

http://stackoverflow.com/questions/16526211/how-should-a-client-pass-a-facebook-access-token-to-the-server

— Reply to this email directly or view it on GitHubhttps://github.com/wufm/osdi-docs/issues/48#issuecomment-28519922 .

[BrianVallelunga]

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.

[j-ro]

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).

[j-ro]

BTW, pull request for basic security/authentication section available for review here:

https://github.com/wufm/osdi-docs/pull/54

[BrianVallelunga]

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.

[joshco]

close per 11/21 approval