Shane B Weeden <swee...@au1.ibm.com> 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. > >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). I hope it was delicious :-). Pls. note: Mark & Phil were involved as well. 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. In my opinion, there are the following advantages: - the user can be provided with trustworthy information about the client - the authentication is a further measure against guessing attacks on authz codes and refresh tokens (beside high entropy and short duration) - it might make token theft more difficult given the secret is stored somewhere/somehow else than the refresh tokens regards, Torsten. > > > > > >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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
