+1 for John's suggestion. Why force users to re-authenticate after an arbitrary 30-day window?
On Fri, Aug 28, 2015 at 1:41 PM John Bradley <ve7...@ve7jtb.com> wrote: > I would use a 5 min AT and roll the refresh token per > https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that > is what you want for a inactivity timeout after which the user must > authenticate again. The user can always revoke the refresh token. > > Rolling the refresh token also has the advantage that if the token leaks > or is stollen then you will detect the second use of the expired refresh > token and invalidate both, so the user needs to loggin. > > In general I think rolling the refresh token is a good idea though it is > not popular, I think it is more secure. > > John B. > > > > On Aug 28, 2015, at 11:21 AM, Donghwan Kim <flowersinthes...@gmail.com> > wrote: > > I'm sorry to introduce a common topic. > > As John has suggested, I'm going to design that > > * An access token should be short lived e.g. 5 minutes (not to hit the AS > to verify the token or 1 hour (to hit the AS to verify the token). I'm > inclined to 5 minutes for stateless architecture of RSs. > * A refresh token should have 1 month of expiration time by default. If it > turns out that some access token expired, its refresh token should refresh > the token. Then, so called persistent login can be implemented regardless > of the form of authentication. Only if it fails for some reason e.g. token > revocation or inactivity for 1 month, a user is logged out automatically > and should log in again. > * A refresh token should be able to be revoked somehow. With 5 minutes > approach, it will invalidate only the refresh token (Yes the attacker can > have 5 minutes at most), and with 1 hour approach, it will invalidate the > refresh token as well as the corresponding access token. > > Thanks, > > -- Donghwan > > On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Refresh tokens are also used by public clients, e.g. native apps. OIDC >> allows to acquire a new id token from a refresh token as well. Note: this >> does not mean a fresh authentication but a refreshed id token containing >> the data of the original authentication transaction. >> >> Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley <ve7...@ve7jtb.com >> >: >>> >>> I think Nat’s diagram about the problems of doing pseudo authentication >>> with OAuth is being taken out of context. >>> >>> The refresh token dosen’t expire, it is revoked by the user or system. >>> In some cases refresh tokens are automatically revoked if the users session >>> to the AS ends. I think AOL typically revokes refresh tokens when sessions >>> terminate. >>> >>> OpenID Connect provides a separate id_token with a independent lifetime >>> from the refresh token. A client may keep a refresh token for a much >>> longer time than the user has a login session with the AS. >>> >>> Refresh tokens are typically used by confidential clients that are using >>> a client secret in combination with the refresh token for getting a new >>> access token. >>> >>> By design access tokens should be short lived as the AS is expected to >>> have a way of revoking refresh tokens but not access tokens. >>> A access token that dosen't expire , and can’t be revoked is not a good >>> idea. >>> >>> John B. >>> >>> >>> On Aug 24, 2015, at 2:41 AM, Donghwan Kim <flowersinthes...@gmail.com> >>> wrote: >>> >>> Hi, >>> >>> According to Figure 2 from >>> http://tools.ietf.org/html/rfc6749#section-1.5, refresh token can be >>> used to refresh an expired access token without requesting resource owner >>> to sign in again (uncomfortable experience). However, if it's true, isn't >>> it that refresh token might be used to request a new access token even >>> years later? and then isn't refresh token the same with access token which >>> never expires? >>> >>> I intended to use refresh token to implement persistent login by sending >>> a refresh request before issued access token expires (expires_in runs out). >>> But if refresh token works even if access token expired already, sending a >>> refresh request on application start up would be enough. >>> >>> So I'm not sure what I'm missing about refresh token as well as how to >>> implement persistent login using it (you can regard authentication here >>> pseudo-authentication illustrated in >>> https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg). >>> What is the lifetime of refresh token? >>> >>> Thanks, >>> >>> -- Donghwan >>> _______________________________________________ >>> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
