The latest demo application I have actually has two modes of registration - the one that I show in the video is indeed the authorization code flow with manual delivery of the code however there is another registration panel which allows the resource owner to type in their U/P and then it does indeed use the resource owner password credentials flow with a public client id. The reason I chose that rather than simple client_credentials flow is that only the resource owner password credentials flow (and azn code) issues a refresh token which is central to the pattern.
The rest of your discussion about public clients and the token endpoint authentication is accurate - it is essential that the resource owner securely deliver the authorization code to the client - this is really what is identifying that instance of the client. This is written up reasonably well in the threat model doc. Cheers, Shane. From: Sergey Beryozkin <[email protected]> To: Shane B Weeden/Australia/IBM@IBMAU Cc: [email protected] Date: 03/04/2013 06:23 PM Subject: Re: [OAUTH-WG] OAuth mobile flow Hi Shane, All, The info below (and the links shared by others) is useful, thanks, I have a single question really which hopefully won't be off-topic, On 25/03/13 14:55, Shane B Weeden wrote: > 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. Why do you refer to the "resource owner password credentials flow" with a public client id ? I see that the resource owner does indeed authenticate and then authorizes a given mobile client application, but effectively it is an authorization code flow 'minus' the redirect from the confidential client (which the mobile app is not in this case), so the RO simply directly invokes on the authorization endpoint, omitting an otherwise required "redirect_uri" - which in itself is not a RO password credentials flow. As a side note I guess I also start appreciating how does a token endpoint can 'authenticate' a public client like 'mobileClient' without it also offering a password/etc, the assumption is that the code obtained earlier must've been provided to the mobile application securely, so effectively it is the (public) client_id + the grant (whatever it is, securely obtained by the client) that the token endpoint works with: I'm not sure yet if it can affect the common processing path in the token endpoint or not, probably not, because the public client must've been marked as such during the registration, so the token endpoint can accept a client_id only (without any credentials like password), as far as the authentication is concerned Thanks, Sergey > > Regards, > Shane. > > > > > > From: Sergey Beryozkin<[email protected]> > To: [email protected] > Date: 25/03/2013 06:01 PM > Subject: Re: [OAUTH-WG] OAuth mobile flow > Sent by: [email protected] > > > > 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. >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
