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 backchanne l 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
