Hey Greg, I think that the Client Identifier and Secret flow should address this. It definitely needs to be called out better.
--David On Mon, Mar 22, 2010 at 2:23 PM, Greg Brail <gbr...@sonoasystems.com> wrote: > 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
