What I did in my OAuth 2.0 server environment was allow a client to self-register without a redirect URI. If they do that, then use the azncode flow, the azncode is displayed on the screen and the resource owner figures out for themselves how to get it to the client. Quite similar in principal to oob in OAuth 1.0 as you suggested. And yes - you can even try that pattern out for yourself on my demo OAuth server. Take a read of https://www-304.ibm.com/connections/blogs/sweeden/entry/oauth_demonstration_environment for details on how to get yourself a client_id. I do some custom stuff for mobileClient - like shrink the authorization code to six lowercase chars and reduce it's lifetime to 60 seconds so it can be more easily typed into a phone keyboard, but ultimately that's just config.
In my demos you saw two options for delivery - type it in, or scan it in via QR. Obviously there are several security and operational considerations to think about, but ultimately provided the resource owner does securely deliver the code to the client it's fundamentally ok. You can get more elaborate than that for mobile scenarios - for example you can use a web view of the mobile application itself to interact with the resource owner then send the azncode back via a push notification service. This has rouge app / password phishing implications that I don't like and is no better from a security perspective than doing resource owner password credentials flow with a public client id, but again it's still a possibility. Regards, Shane. From: Sergey Beryozkin <sberyoz...@gmail.com> To: oauth@ietf.org Date: 25/03/2013 06:01 PM Subject: Re: [OAUTH-WG] OAuth mobile flow Sent by: oauth-boun...@ietf.org Hi Shane On 25/03/13 00:54, Shane B Weeden wrote: > There are several options. I've developed a few based on azn code flow with > custom "delivery" of the code, and also resource owner password credentials > flow with a public client id (although I personally don't like the idea of > ever presenting my real credentials to the phone but business owners seem > to still want to do that). > > These might give you an idea: > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood > http://www.youtube.com/watch?v=cLLrZMt_hII This is interesting, thank you. I'm just wondering, how does you application decide that the access token is to be returned effectively out of band (which reminds me of the 'oob' redirect uri from OAuth 1.0). Looks like the client_id being equal to "mobileClient" (in your demo) is a hint. If yes, then would you (and others) see any benefit in actually attempting to get an 'oob' redirect_uri value standardized ? (sorry if this was already raised earlier). I can see how I can get a generic framework for supporting writing OAuth2 applications returning the code directly to the browser even without having 'oob' redirect uri - example, one can configure the authorization endpoint to recognize that a particular client_id requires an out of band delivery of the access token, etc. FYI, I like the device code flow you linked to though appreciate the simplicity of returning the token to the browser in demos, etc... Cheers, Sergey > > Regards, > Shane. > > > > From: Security Developer<security.develope...@gmail.com> > To: OAuth@ietf.org > Date: 25/03/2013 05:52 AM > Subject: [OAUTH-WG] OAuth mobile flow > Sent by: oauth-boun...@ietf.org > > > > Hi, > > Can any body please help in describing the OAuth flow for mobile > applications? > > Thanks for your time._______________________________________________ > 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 _______________________________________________ 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
