Again, I would state that this is all contextual to the application
being built - which is why the RFC never gives specific times other than
"short lived" or "long lived". I would suggest giving a series of
recommendations relative to a few different risk profiles (low risk,
social media, banking, enterprise, etc) as opposed to one recommendation.
With respect,
Jim Manico
On 8/28/15 10:41 AM, John Bradley 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 <mailto: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 <mailto: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 <mailto: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
<mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
------------------------------------------------------------------------
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
