This is all contextual to the application. In some situations I want to
immediately force re-authentication for all transactions above X$ such
as banking applications. In some situations I want a permanent refresh
token, like for Twitter like social applications. etc...etc...
- Jim Manico
On 8/28/15 10:58 AM, William Denniss wrote:
+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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[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] <mailto:[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] <mailto:[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
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
<[email protected]
<mailto:[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 refresh token?
Thanks,
-- Donghwan
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
------------------------------------------------------------------------
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
