As I understand it, what you've described is precisely the intent of the refresh token. The online registration process you refer to is a corresponding one-time authorization code flow. The authorization code effectively becomes a one-time-use, short-lived credential for the client instance which it should use immediately (since it has been exposed to the resource owner via the user-agent in getting to the client) to directly request an access token (typically short-lived and may not be needed immediately) and refresh token (typically long-lived). The refresh token is stored securely locally. It is essentially an instance secret bound to the client id and representing the original resource owner grant. Provided: 1. The resource owner and user-agent safely deliver the authorization code to the client instance in first place 2. The client uses it immediately in secure transport-level communications to the authorization server and then securely stores the long-lived refresh token 3. The client always uses the refresh token in secure transport-level communications to the authorization server to get an access token (and optionally rollover the refresh token) .. then securely authenticating the client doesn't seem to be a big deal.
I trust "the list" will correct me if that's a wrong interpretation of a classic native app scenario. It still leads to my question from some posts ago about why then is it advantageous to require client authentication at all for the authorization code flow in classic web app three-legged scenarios, and I am yet to fully digest Torsten's response to that ( http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01). About the only documented advantage I've seen to date has to do with the recovery/next steps from a compromised refresh token, but the usefulness of that idea has been debated as well. From: Dave Nelson <dnel...@elbrys.com> To: Brian Eaton <bea...@google.com> Cc: "oauth@ietf.org" <oauth@ietf.org> Date: 17-06-11 09:45 PM Subject: Re: [OAUTH-WG] Client authentication requirement Sent by: oauth-boun...@ietf.org > If you aren't willing to accept the risk of native apps that can't keep > secrets, don't support such apps. We continue to say "can't keep secrets". I think what we mean is "can't keep secrets that are embedded in the code". One could imagine an install-time, leap-of-faith binding to a remotely received secret, via some on-line registration process, that the native app asks the operating system to store for it securely. The user can make an assertion of trust in the validity of the app that he/she has downloaded and is subsequently installing. Of course, that initial faith might be misplaced, but that's true of almost all user-installable software, even that receive on physical media. If browsers are trusted to store secrets securely, then that same capability is available to native apps. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
