Re: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients

["Stein Desmet" <[e-mail]>]

Thank you for your reply. We've indeed decided to go with the  
authorization flow like you suggested, because:
- the client credentials flow would require a timeout for user  
registration (to handle idle users)
   However, it seems that you might as well use the authorization flow in  
that case, as it works
   like an OTP of sorts (as you pointed out). The authorization flow also  
has the state field,
   which solves other possible security issues with user/client  
registration in the client credentials
   flow.
- Support for the authorization flow is wider than for the others  
(including device flow)
- Implementing the authorization flow has the added benefit that we can  
immediately
   use Oauth as an alternative to our openid and saml authentication  
options.

Best regards,
Stein Desmet


On Mon, 12 Mar 2012 16:39:10 +0100, Richer, Justin P. <[e-mail]>  
wrote:

> Client credentials is not the right flow for this approach since there's  
> a user present at the client and they can close the loop for you. The  
> Device Flow, if it were to get picked up and fleshed out a bit, is a  
> better fit for what you're after and is made for just such a  
> disconnected world where you can't rely on the user logging in through a  
> browser that's easily accessible from the client app.
>
> Another, arguably better, approach would be to use the vanilla Authz  
> Code flow, taking advantage of the fact that the code is itself a OTP.  
> First, have the ClientID embedded in the mobile app, like normal. Since  
> it's a configuration time piece of information that gets copied to every  
> instance, you wouldn't use a client secret here. (It doesn't buy you  
> anything.) Next, direct your users to log into a server-side "help app",  
> which is basically just the Authz Server's authorization endpoint that's  
> been seeded with the client ID, scope, and other relevant parameters.  
> This is easy enough to do by giving your users a short URL  to go go  
> that starts off this process automatically. Next, the user goes through  
> all the normal OAuth stuff and gets redirected to a pre-registered  
> callback URL. This callback URL is hosted by your service, not by the  
> device itself. The page would then display the code so that the user  
> could type it in, present a QRCode to scan in, do some kind of  
> backchannel trusted pass, or a few other tricks to get the code from the  
> hosted site over to the device itself. Then the device uses the code,  
> which you remember is a OTP that's hopefully time limited, along with  
> its client ID to go and grab the access tokens that it needs.
>
>  -- Justin
>
>
> On Mar 9, 2012, at 5:19 AM, Stein Desmet wrote:
>
>> I have mistakingly asked this question on the google group on google's
>> Oauth2 implementation, so here it is at the correct place (I hope).
>>
>> We have an authentication server/identity provider, and a number of
>> external web applications (ie resource servers) that make use of it.
>> We would like to build native applications (iOS/Android) that make use  
>> of
>> the resources on these web applications, so adding Oauht2 to
>> both our authentication server and our web applications to provide
>> authorization seems ideal.
>>
>> However, there is one issue: it is possible for end-users to  
>> authenticate
>> themselves using smartcards or electronic ids (these users do not have
>> a login/password at all). Therefore, we can't use embedded user-agents,  
>> or
>> external user agents located on the mobile platform itself, so users
>> would need to use a browser on another computer. However, I'm not  
>> entirely
>> sure which flow is best applicable in such a case, and offers the best
>> security?
>>
>> - The client credentials flow seems like a fit. Users would need to
>> register their mobile device on the authentication server first, meaning
>> they
>>    are issued a client id and secret, unique to each client instance.  
>> These
>> credentials could be transferred in a number of ways, using QR codes,
>>    or have the user manually input them.
>> - The authorization grant flow can also be used. The flow would be  
>> started
>> on a separate browser using a helper web client app, and at the end
>>    of the flow, the authorization code is transferred to the native  
>> client
>> by for example push notifications, QR codes or having the user manually
>>    input it. Client credentials in this case would be universal for the
>> native application.
>>    This seems a bit harder to implement (and care must betaken to avoid
>> exploitation of the web client app), but the refresh tokens could be  
>> used
>>    as OTP (i.e. issuing a new refresh token each time a user asks for a  
>> new
>> access token, and invalidating the previous one), allowing some  
>> detection
>>    of misuse.
>>
>> The device flow seems applicable as well, but is no longer present in
>> recent Oauht2 drafts (though there is still
>> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00).
>>
>> Best regards,
>> Stein Desmet
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth