Re: [OAUTH-WG] Lifetime of refresh token
@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 <j...@manicode.com> 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> > 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 > > 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 sessi
Re: [OAUTH-WG] Lifetime of refresh token
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 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] Is it allow to add custom attribute to access token response?
Hi folks,
First off, I appreciate your answers.
What I try to do with OAuth is to design a set of APIs which allow to write
application without server in a standard-compliant way and I chose OAuth
for the social web. Because the current API I work on uses a kind
of Form-based authentication (
https://en.wikipedia.org/wiki/Form-based_authentication), I started
with Resource Owner Password Credentials first to support other grant types
gracefully later. Here I faced the problem with authentication. (Now I
realized that I may have abused OAuth according to your answers)
My thought is to use access_token as a session token containing values like
roles not just a reference on server's memory indicating such values
(traditional cookie). That means access_token should be a JSON Web Token
(JWT) which contains usename (to log who did an action), roles (ACL, to
determine this request has a proper permission), and so on. Then every
server (or microservice unit) accepting request doesn't need to have not
only session states in its memory (stateless), but also a dependency with
auth server because access_token included in Authorization request header
as bearer token contains all about authentication and authorization
information. Having said that, because token would be not valid over time
if values contained in the token might be changed e.g. role or due to
OAuth's expiration mechanism, removing dependency with auth server is
unlikely to be feasible practically IMO. (Then it would be better for
access_token to be reference rather than a set of values)
As for the original question, as Bill pointed, it's okay to get user
information by username through other separate endpoint for that purpose
(like /userinfo from the context of OpenID Connect (OIDC)). Though, I
wanted to reduce round-trip by adding a custom property to token endpoint's
response.
Here's some questions:
1. Is it an abuse of OAuth to use access_token as a session token which is
a set of values not reference on server indicating values? or what if it is
in the form of reference? As far as I read
https://tools.ietf.org/html/rfc6749, I didn't feel that access_token should
not be like that. On the contrary, if I introduce another standard for
authentication, API implementators should do more work and I didn't want to
do that. In this case, support for OIDC can be regarded as enhancement of
API like Google did
https://developers.google.com/+/web/api/rest/openidconnect/
If not or it doesn't sound that good, I'll take a look
https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 and
http://openid.net/specs/openid-connect-core-1_0.html which you suggested.
(Though I'm not comfortable that OIDC is also regarded abuse of OAuth
according to http://security.stackexchange.com/a/44614)
Thanks!
-- Donghwan
On Sat, Aug 22, 2015 at 1:42 AM, William Denniss wdenn...@google.com
wrote:
As for your specific use-case though, as John said it's better to use
OpenID Connect which provides a solution for what you are trying to do
already.
That way you get an interoperable solution, and one that has been vetted
by security experts. There is even a free test suite
http://openid.net/certification/testing/ for you to test your
implementation.
On Fri, Aug 21, 2015 at 9:35 AM, John Bradley ve7...@ve7jtb.com wrote:
Requests to the token endpoint are URL form encoded not JSON in your
example.
The use of the password credentials grant was to allow migration from
HTTP basic, but it not recommended for privacy and security reasons.
OpenID Connect is a better way to authenticate users.
However assuming you have a closed system and don’t care about
interoperability between clients and the Token endpoint, you could just add
that parameter to your AS and the world will not end.
If you want to have interoperable clients then you should register the
new element in the IANA registry Sec 11.2 of the spec.
Parameter name:
The name requested (e.g., “username).
Parameter usage location:
token response.
Change controller:
For Standards Track RFCs, state IETF. For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included.
You need to have a specification to do that.
I don’t see this as a good idea, but that is how you would do it.
Regards
John B.
On Aug 20, 2015, at 11:15 AM, Donghwan Kim flowersinthes...@gmail.com
wrote:
Hi,
I would like to add a custom property representing the account who just
authenticated to the access token response for the sake of convenience like
login request's response. Then, an exchange of request and response will
look like this:
POST /tokens HTTP/1.1
Host: api.example.com
Content-Type: application/json
{grant_type:password,username:${username},password:${password}}
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
access_token:${JSON
[OAUTH-WG] Lifetime of refresh token
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] Is it allow to add custom attribute to access token response?
Hi,
Requests to the token endpoint are URL form encoded not JSON in your
example.
My bad.
According to http://tools.ietf.org/html/rfc6749#section-4.3,
application/x-www-form-urlencoded not application/json is correct for token
endpoint request's content type. Right?
Thanks,
-- Donghwan
On Sat, Aug 22, 2015 at 1:35 AM, John Bradley ve7...@ve7jtb.com wrote:
Requests to the token endpoint are URL form encoded not JSON in your
example.
The use of the password credentials grant was to allow migration from HTTP
basic, but it not recommended for privacy and security reasons.
OpenID Connect is a better way to authenticate users.
However assuming you have a closed system and don’t care about
interoperability between clients and the Token endpoint, you could just add
that parameter to your AS and the world will not end.
If you want to have interoperable clients then you should register the new
element in the IANA registry Sec 11.2 of the spec.
Parameter name:
The name requested (e.g., “username).
Parameter usage location:
token response.
Change controller:
For Standards Track RFCs, state IETF. For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included.
You need to have a specification to do that.
I don’t see this as a good idea, but that is how you would do it.
Regards
John B.
On Aug 20, 2015, at 11:15 AM, Donghwan Kim flowersinthes...@gmail.com
wrote:
Hi,
I would like to add a custom property representing the account who just
authenticated to the access token response for the sake of convenience like
login request's response. Then, an exchange of request and response will
look like this:
POST /tokens HTTP/1.1
Host: api.example.com
Content-Type: application/json
{grant_type:password,username:${username},password:${password}}
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
access_token:${JSON web token},
token_type:Bearer,
account: {username:donghwan, ...}
}
However http://tools.ietf.org/html/rfc6749#section-5.1 says that
The client MUST ignore unrecognized value names in the response.
Does it mean that I shouldn't add such property, 'account'? Though, I saw
Instagram API adds such custom property to access token response for the
same purpose from https://instagram.com/developer/authentication/ (Please
find 'snoopdogg' to see that token response.) If it's not allowed or
desirable, how should I add such information to the access token response?
BTW, I have some questions on usage of JSON web token with OAuth. Can I
post them here? If not, where should I do that?
Thanks,
-- Donghawn
___
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-WG] Is it allow to add custom attribute to access token response?
Hi,
I would like to add a custom property representing the account who just
authenticated to the access token response for the sake of convenience like
login request's response. Then, an exchange of request and response will
look like this:
POST /tokens HTTP/1.1
Host: api.example.com
Content-Type: application/json
{grant_type:password,username:${username},password:${password}}
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
access_token:${JSON web token},
token_type:Bearer,
account: {username:donghwan, ...}
}
However http://tools.ietf.org/html/rfc6749#section-5.1 says that
The client MUST ignore unrecognized value names in the response.
Does it mean that I shouldn't add such property, 'account'? Though, I saw
Instagram API adds such custom property to access token response for the
same purpose from https://instagram.com/developer/authentication/ (Please
find 'snoopdogg' to see that token response.) If it's not allowed or
desirable, how should I add such information to the access token response?
BTW, I have some questions on usage of JSON web token with OAuth. Can I
post them here? If not, where should I do that?
Thanks,
-- Donghawn
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
