I'd like to describe a token-related use case that, right now, is how some people are using parts of OAuth 1.0. I think it's a real use case and I'm wondering how the proposed OAuth 2.0 would handle it. (I'm on the IETF call too and it is very quiet.)
We have seen APIs out there that require that the "application" or device be authenticated, but not necessarily the individual user. This happens in mobile apps, for instance -- there is a requirement to identify which mobile app, version, platform, etc, is making API calls. However, the data being retrieved is not terribly sensitive and does not require user-level authentication. The standard way to handle this in the API world today is by using the "API key" pattern -- a unique identifier is handed to every application, buried in the code somewhere, and used on every API call. Some users of APIs want a layer of security in between a simple API key (a bearer token) and full OAuth-based user authentication. They do this today using the OAuth 1.0 "consumer key" -- they bury a consumer key and secret inside the mobile device, and use the OAuth 1.0 signature mechanism to sign each request using the key and secret. This gives them a reasonable amount of assurance that requests are coming from a particular version of the mobile app, while not requiring full user authentication. (Some people call this "one-legged OAuth.") Furthermore, some existing OAuth 1.0-based APIs -- or at least the Netflix API -- use different levels of authentication for different calls, depending on the sensitivity of the data involved. To use OAuth 1.0a terminology, certain calls require a "consumer key only," others must be signed using the consumer key and secret, and others must be signed by a consumer key and access token. Eran's proposal from a while ago to split OAuth into "how to get a token" and "how to use a token" handled this nicely because customers involved in this kind of use case could select only the "how to use a token" part of the spec when they planned to use only a small number of tokens and distribute them manually. It seems like the current OAuth 2.0 proposal is a little different. I'd like to make sure that this use case still works in the final specs.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
