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

From: "Stein Desmet" <[email-masked]>
Date: Fri, 09 Mar 2012 11:19:16 +0100

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 12 Mar 2012 15:39:10 +0000

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:

>    are issued a client id and secret, unique to each client instance. These
>    as OTP (i.e. issuing a new refresh token each time a user asks for a new
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Shane B Weeden <[email-masked]>
Date: Tue, 13 Mar 2012 08:28:09 +1000

You're on the right track.
If you're interested, I have a demo of exactly what you are talking about
using the authorization code flow (and in this case manual entry of the
short-lived azn code). It uses refresh tokens precisely just as you
suggest:

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

You'll see that a client secret is not required at all as native mobile
clients are really public.

My server is currently offline, but I'll be bringing it back up again in
the next couple of days then you can try it our directly.

From:	"Stein Desmet" <[email-masked]>
To:	[email-masked]
Date:	13/03/2012 01:20 AM
Subject:	[OAUTH-WG] Client credentials flow vs. authorization grant flow
            for native clients
Sent by:	[email-masked]

     of the flow, the authorization code is transferred to the native
client

Best regards,
Stein Desmet

---

From: "Stein Desmet" <[email-masked]>
Date: Wed, 14 Mar 2012 16:51:41 +0100

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. <[email-masked]>  
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
>
>