You don't need to put an expiration on the refresh token. You get to see that
refresh token every 5 minutes anyway. If you ever want to force the client to
re-auth just use policy on the AS. Nothing will be broken with what you are
doing though.
On Friday, August 28, 2015 7:21 AM, Donghwan Kim
<[email protected]> 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 <[email protected]>
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 <[email protected]>:
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 isexpected 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 <[email protected]> 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 refreshtoken?
Thanks,
-- Donghwan_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
