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 protected]> To: [email protected] Date: 13/03/2012 01:20 AM Subject: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients Sent by: [email protected] 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
