> From: [email protected] [mailto:[email protected]] On Behalf > Of Torsten Lodderstedt > Sent: Friday, June 17, 2011 11:31 AM > To: Shane B Weeden; Dave Nelson > Cc: [email protected] > Subject: Re: [OAUTH-WG] Client authentication requirement > > Shane B Weeden <[email protected]> schrieb: > > >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. > > I fully agree with your description. >
Shane: The issue is actually best summarized by your own email. Client authentication is not needed provided (1), (2) and (3). This is a lot of assumptions to rely on. > > 1. The resource owner and user-agent safely deliver the > > authorization code to the client instance in first place What does "safely deliver" mean? How is it implemented and deployed? > > 2. The client uses it > > immediately in secure transport-level communications > > to the authorization server and then securely stores > > the long-lived refresh token. What is the time-limit for "immediately"? (60 secs, 30 mins, 24hr?). > > 3. The client always uses the refresh token in secure > > transport-level communications to the authorization > > server to get an access token Oauth2.0-draft16 only devotes two lines to X509 certificates (Section 10.6), for the authorization-server and client interaction. Its not clear how binding is done (eg. binding of the TLS session and transaction), for example for audit/logging purposes. /thomas/ _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
