Subject: [OAUTH-WG] Lifetime of refresh token

From: Donghwan Kim <[email-masked]>
Date: Mon, 24 Aug 2015 14:41:34 +0900

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 24 Aug 2015 10:45:51 -0400

The lifetime of a refresh token is up to the AS — they can expire, be revoked, etc. The difference between a refresh token and an access token is the audience: the refresh token only goes back to the AS, the access token goes to the RS. 

Also, just getting an access token doesn’t mean the user’s logged in. In fact, the user might not even be there anymore, which is actually the intended use case of the refresh token. Refreshing the access token will give you access to an API on the user’s behalf, it will not tell you if the user’s there.

OpenID Connect doesn’t just give you user information from an access token, it also gives you an ID token. This is a separate piece of data that’s directed at the client itself, not the AS or the RS. In OIDC, you should only consider someone actually “logged in” by the protocol if you can get a fresh ID token. Refreshing it is not likely to be enough.

 — Justin

> On Aug 24, 2015, at 1:41 AM, Donghwan Kim <[email-masked]> wrote:
> 
> Hi,
> 
> According to Figure 2 from http://tools.ietf.org/html/rfc6749#section-1.5 <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 <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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Mon, 24 Aug 2015 12:08:21 -0300

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-masked]> wrote:
> 
> Hi,
>

---

From: Jim Manico <[email-masked]>
Date: Mon, 24 Aug 2015 09:12:35 -0600

There is a good debate and discussion on refresh tokens on StackOverflow. 

http://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens

Is this a good place to send developers to answer refresh token questions, and if not, can the illustrious smart people on this list update StackOverflow if necessary?

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

> On Aug 23, 2015, at 11:41 PM, Donghwan Kim <[email-masked]> 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?
> 
> 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

---

From: Bill Mills <[email-masked]>
Date: Mon, 24 Aug 2015 17:01:10 +0000 (UTC)

You could have a refresh token that never expires.  Having to use the refresh token to get a new access token gives you a single control point to allow checking whether that refresh token should still be valid.  Means the RS doesn't have to do that stuff. 

     On Monday, August 24, 2015 8:09 AM, John Bradley <[email-masked]> wrote:

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.

-- Donghwan_______________________________________________

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 28 Aug 2015 10:43:52 +0200

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-masked]>:
>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.
>> According to Figure 2 from
>http://tools.ietf.org/html/rfc6749#section-1.5
><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
><https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg>).
>------------------------------------------------------------------------
>

---

From: Donghwan Kim <[email-masked]>
Date: Fri, 28 Aug 2015 23:21:41 +0900

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-masked]> 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-masked]
> >:
>>
>> 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.
>>
>> 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.
>>
>> I intended to use refresh token to implement persistent login by sending
>> a refresh request before issued access token expires (expires_in runs out).
>> ------------------------------
>>
>> OAuth mailing list
>> [email-masked]

---

From: Bill Mills <[email-masked]>
Date: Fri, 28 Aug 2015 15:14:54 +0000 (UTC)

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-masked]> 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-masked]> wrote:

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.

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-masked]
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Fri, 28 Aug 2015 12:20:51 -0400

One viable method for detecting “inactivity for one month” would be to have a one month expiration on the refresh token, but reset that counter every time the refresh token is used to get a new access token. You can do this by manipulating the expiration of the token object itself on your authorization server, or you can just throw away the old refresh token and create a new one with an expiration one month out. Each of these methods has its benefits and pitfalls.

 — Justin

> On Aug 28, 2015, at 10:21 AM, Donghwan Kim <[email-masked]> wrote:
> 
> * 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-masked] <mailto:[email-masked]>> wrote:
> Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley <[email-masked] <mailto:[email-masked]>>:
>> On Aug 24, 2015, at 2:41 AM, Donghwan Kim <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 28 Aug 2015 17:41:30 -0300

I would use a 5 min AT and roll the refresh token per https://tools.ietf.org/html/rfc6749#page-47 <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-masked]> wrote:
>

---

From: William Denniss <[email-masked]>
Date: Fri, 28 Aug 2015 20:58:09 +0000

+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-masked]> 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.
>
>>> 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?
>>>

---

From: Jim Manico <[email-masked]>
Date: Fri, 28 Aug 2015 11:34:07 -1000

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:
> On Fri, Aug 28, 2015 at 1:41 PM John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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-masked] <mailto:[email-masked]>>
>>     wrote:
>>
>>     * 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-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>>:
>>
>>             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.
>>>             On Aug 24, 2015, at 2:41 AM, Donghwan Kim
>>>             <[email-masked]
>>>             <mailto:[email-masked]>> wrote:
>>>
>>>             Hi,
>>>
>>>             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
>     _______________________________________________ OAuth mailing list
-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Jim Manico <[email-masked]>
Date: Fri, 28 Aug 2015 11:36:44 -1000

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:
> 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.
>
> 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.
>
>
>
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> * 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.
>> 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
>>
>>     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.
>>
>>         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.
>>
>>         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.
>>
>>         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.
>>>         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?
>>>
>>>         token expires (expires_in runs out). But if refresh token
>>>         works even if access token expired already, sending a
>>>         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
-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Jim Manico <[email-masked]>
Date: Fri, 28 Aug 2015 11:38:54 -1000

I stand corrected, the RFC does give specific time recommendations such 
as 10 minutes authorization code recommendation here 
https://tools.ietf.org/html/rfc6749#section-4.1.2 but I think my overall 
point is still valid. :)

Aloha,
Jim

On 8/28/15 11:36 AM, Jim Manico wrote:
> 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 
>> expired refresh token and invalidate both, so the user needs to loggin.
>>
>>> will invalidate the refresh token as well as the corresponding 
>>> access token.
>>>
>>> Thanks,
>>>
>>> -- Donghwan
>>>
>>> <[email-masked]> wrote:
>>>
>>>     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
>>>     <[email-masked]>:
>>>         keep a refresh token for a much longer time than the user
>>>         has a login session with the AS.
>>>
>>>>         <[email-masked]> wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         (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?
>>>>
>>>>         well as how to implement persistent login using it (you can
>>>>         regard authentication here pseudo-authentication
>>>>         illustrated in
-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Donghwan Kim <[email-masked]>
Date: Sat, 29 Aug 2015 13:26:40 +0900

@John, @William I'm of exactly the same opinion. When refreshing the token
on expiration of the access token, a new exchange of access token and
refresh token should be issued unless that refresh token expired due to
inactivity of 1 month or is invalidated by user through their some setting
pages. Then, new 1 month of expiration starts again, which is what I called
the persistent login.

@Bill Come to think of it, it makes sense. If user lose his/her phone or
something, he/she should invalidate the token issued to that device.
Waiting for one month doesn't help.

@Jim Your point is quite valid :) BTW, a self-descriptive access token that
only the server understand may be able to cover some of profiles. For
example, if the access token contains when the user is signed, banking
resource server can ask user to sign in again, insisting such operation
should be performed only within 10 minutes of signing in.

Thanks for all replies!

-- Donghwan

On Sat, Aug 29, 2015 at 6:38 AM, Jim Manico <[email-masked]> wrote:

> I stand corrected, the RFC does give specific time recommendations such as
> 10 minutes authorization code recommendation here
> 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
>
> <https://tools.ietf.org/html/rfc6749#page-47>
>>> On Aug 24, 2015, at 2:41 AM, Donghwan Kim < <[email-masked]>
>>> [email-masked]> wrote:
>>>
>>> Hi,
>>>
>>> <http://tools.ietf.org/html/rfc6749#section-1.5>
>>> <https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg>
>>> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
>