subject:"\[OAUTH\-WG\] Lifetime of refresh token"

Re: [OAUTH-WG] Lifetime of refresh token

2015-09-01 Thread Nat Sakimura

Right. I wrote “pseudo-authentication” because it does not qualify as 
authentication. 

In another word, I am saying “DO NOT DO IT.”

 

-- 

Nat Sakimura < <mailto:n-sakim...@nri.co.jp> n-sakim...@nri.co.jp>

Nomura Research Institute, Ltd. 

 

PLEASE READ:

The information contained in this e-mail is confidential and intended for the 
named recipient(s) only.

If you are not an intended recipient of this e-mail, you are hereby notified 
that any review, dissemination, distribution or duplication of this message is 
strictly prohibited. If you have received this message in error, please notify 
the sender immediately and delete your copy from your system.

 

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, August 25, 2015 12:08 AM
To: Donghwan Kim <flowersinthes...@gmail.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Lifetime of refresh token

 

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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-31 Thread Donghwan Kim

@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  wrote:

> 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:
>
> 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 
> 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 :
>>
>>>
>>> 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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread Torsten Lodderstedt

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
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
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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread Bill Mills

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
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:

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 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 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 refreshtoken?
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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread Donghwan Kim

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.

John B.

On Aug 24, 2015, at 2:41 AM, Donghwan Kim flowersinthes...@gmail.com
wrote:

Hi,

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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread Justin Richer

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 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
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.

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

OAuth mailing list
OAuth@ietf.org mailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread Jim Manico

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 ve7...@ve7jtb.com 
mailto: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 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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread Jim Manico

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,

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).

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread Jim Manico

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:
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 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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread William Denniss

+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

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.

John B.

On Aug 24, 2015, at 2:41 AM, Donghwan Kim flowersinthes...@gmail.com
wrote:

Hi,

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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-28 Thread John Bradley

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 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

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
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.

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

OAuth mailing list
OAuth@ietf.org mailto:OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
https://www.ietf.org/mailman/listinfo/oauth

smime.p7s
Description: S/MIME cryptographic signature

[OAUTH-WG] Lifetime of refresh token

2015-08-24 Thread Donghwan Kim

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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-24 Thread Jim Manico

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 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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-24 Thread John Bradley

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
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.

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

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-24 Thread Justin Richer

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 flowersinthes...@gmail.com 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.

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

Re: [OAUTH-WG] Lifetime of refresh token

2015-08-24 Thread Bill Mills

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 ve7...@ve7jtb.com wrote:

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

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

[OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

Re: [OAUTH-WG] Lifetime of refresh token

16 matches

Site Navigation

Mail list logo

Footer information