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

Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.

One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

Hi George,

if you want to effectively preseve the refresh token, why doesn't the AS just treat the new client id as an alias of the the old client id?

regards,
Torsten.

-------- Ursprüngliche Nachricht --------
Von: George Fletcher <gffletch@aol.com> 
Datum:03.04.2014  15:43  (GMT+01:00) 
An: Torsten Lodderstedt <torsten@lodderstedt.net>,Phil Hunt <phil.hunt@oracle.com> 
Cc: OAuth WG <oauth@ietf.org> 
Betreff: Re: [OAUTH-WG] Handling stored tokens in mobile app after software update with client credential change 

Hi Torsten,

We actually have the same issue. Deployed clients in the field where we want to update the client_id and doing so invalidates the existing refresh_token stored with the client. From a user experience perspective, this is a pain and from a risk perspective I think it's fine to effectively do a "token exchange" from the old refresh_token to the new one (with the appropriate security considerations in mind).

Andre got me thinking about this and here is what I'm leaning towards implementing in our system.

Use the JWT Client Assertion flow requesting an authorization grant for the existing user. The JWT would contain an "iss" of the new client_id, a "sub" of the userid the client should already know about, an "aud" of the Authorization Server, a short lived "exp" value as this is effectively a one-time token exchange, and an additional claim of the old refresh_token. Maybe an additional claim with the old client_id as well (still thinking about that as the client_id is already associated with the refresh_token).

This allows the AS to do the following checks...
1. Make sure the assertion is being presented by the new client (the level of surety is based on the risk associated with the client. If the client is provisioned with additional keys some how that's much stronger than just using a client_secret which, as you point out, doesn't really prove anything).
2. Verify that the "sub" value in the JWT is the same as that identified by the refresh_token
3. Verify that the client_id defined as the "issuer" is allowed to make this token exchange call and that the client_id in the refresh_token is one of those being replaced
4. Verify the audience of the JWT

If all the checks pass, then a new refresh_token can be issued, with exactly the same scopes as the "old" refresh_token (no ability in this flow to change scopes). The semantics of the refresh_token (e.g. authN time, expiry time, etc) need to be copied to the new refresh_token. In other words there should be no way to "extend" the lifetime of the refresh_token via this mechanism. It's purely a token exchange to provide a new refresh_token mapped to the new client_id.

Interested in feedback as to the viability of this.

Phil, I agree this doesn't need to be standardized, and I would like to see the community start collecting some "best practices" to help others that come across the same use case. It will ensure       a more secure internet for all of us.

Thanks,
George

On 4/3/14, 6:13 AM, Torsten Lodderstedt wrote:
Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.

One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.

One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

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

Hi George,

if you want to effectively preseve the refresh token, why doesn't the AS just treat the new client id as an alias of the the old client id?

regards,
Torsten.

-------- Ursprüngliche Nachricht --------
Von: George Fletcher <gffletch@aol.com> 
Datum:03.04.2014  15:43  (GMT+01:00) 
An: Torsten Lodderstedt <torsten@lodderstedt.net>,Phil Hunt <phil.hunt@oracle.com> 
Cc: OAuth WG <oauth@ietf.org> 
Betreff: Re: [OAUTH-WG] Handling stored tokens in mobile app after software update with client credential change 

Hi Torsten,

We actually have the same issue. Deployed clients in the field where we want to update the client_id and doing so invalidates the existing refresh_token stored with the client. From a user experience perspective, this is a pain and from a risk perspective I think it's fine to effectively do a "token exchange" from the old refresh_token to the new one (with the appropriate security considerations in mind).

Andre got me thinking about this and here is what I'm leaning towards implementing in our system.

Use the JWT Client Assertion flow requesting an authorization grant for the existing user. The JWT would contain an "iss" of the new client_id, a "sub" of the userid the client should already know about, an "aud" of the Authorization Server, a short lived "exp" value as this is effectively a one-time token exchange, and an additional claim of the old refresh_token. Maybe an additional claim with the old client_id as well (still thinking about that as the client_id is already associated with the refresh_token).

This allows the AS to do the following checks...
1. Make sure the assertion is being presented by the new client (the level of surety is based on the risk associated with the client. If the client is provisioned with additional keys some how that's much stronger than just using a client_secret which, as you point out, doesn't really prove anything).
2. Verify that the "sub" value in the JWT is the same as that identified by the refresh_token
3. Verify that the client_id defined as the "issuer" is allowed to make this token exchange call and that the client_id in the refresh_token is one of those being replaced
4. Verify the audience of the JWT

If all the checks pass, then a new refresh_token can be issued, with exactly the same scopes as the "old" refresh_token (no ability in this flow to change scopes). The semantics of the refresh_token (e.g. authN time, expiry time, etc) need to be copied to the new refresh_token. In other words there should be no way to "extend" the lifetime of the refresh_token via this mechanism. It's purely a token exchange to provide a new refresh_token mapped to the new client_id.

Interested in feedback as to the viability of this.

Phil, I agree this doesn't need to be standardized, and I would like to see the community start collecting some "best practices" to help others that come across the same use case. It will ensure       a more secure internet for all of us.

Thanks,
George

On 4/3/14, 6:13 AM, Torsten Lodderstedt wrote:
Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.

One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.

One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

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

Hi George,

if you want to effectively preseve the refresh token, why doesn't the AS =
just treat the new client id as an alias of the the old client id?

regards,
Torsten.

-------- Urspr=FCngliche Nachricht --------
Von: George Fletcher <gffletch@aol.com>=20
Datum:03.04.2014  15:43  (GMT+01:00)=20
An: Torsten Lodderstedt <torsten@lodderstedt.net>,Phil Hunt <phil.hunt@oracle.com>=20
Cc: OAuth WG <oauth@ietf.org>=20
Betreff: Re: [OAUTH-WG] Handling stored tokens in mobile app after =
software update with client credential change=20

Hi Torsten,

We actually have the same issue. Deployed clients in the field where we =
want to update the client_id and doing so invalidates the existing =
refresh_token stored with the client. =46rom a user experience =
perspective, this is a pain and from a risk perspective I think it's =
fine to effectively do a "token exchange" from the old refresh_token to =
the new one (with the appropriate security considerations in mind).

Andre got me thinking about this and here is what I'm leaning towards =
implementing in our system.

Use the JWT Client Assertion flow requesting an authorization grant for =
the existing user. The JWT would contain an "iss" of the new client_id, =
a "sub" of the userid the client should already know about, an "aud" of =
the Authorization Server, a short lived "exp" value as this is =
effectively a one-time token exchange, and an additional claim of the =
old refresh_token. Maybe an additional claim with the old client_id as =
well (still thinking about that as the client_id is already associated =
with the refresh_token).

This allows the AS to do the following checks...
1. Make sure the assertion is being presented by the new client (the =
level of surety is based on the risk associated with the client. If the =
client is provisioned with additional keys some how that's much stronger =
than just using a client_secret which, as you point out, doesn't really =
prove anything).
2. Verify that the "sub" value in the JWT is the same as that identified =
by the refresh_token
3. Verify that the client_id defined as the "issuer" is allowed to make =
this token exchange call and that the client_id in the refresh_token is =
one of those being replaced
4. Verify the audience of the JWT

If all the checks pass, then a new refresh_token can be issued, with =
exactly the same scopes as the "old" refresh_token (no ability in this =
flow to change scopes). The semantics of the refresh_token (e.g. authN =
time, expiry time, etc) need to be copied to the new refresh_token. In =
other words there should be no way to "extend" the lifetime of the =
refresh_token via this mechanism. It's purely a token exchange to =
provide a new refresh_token mapped to the new client_id.

Interested in feedback as to the viability of this.

Phil, I agree this doesn't need to be standardized, and I would like to =
see the community start collecting some "best practices" to help others =
that come across the same use case. It will ensure       a more secure =
internet for all of us.

Thanks,
George

On 4/3/14, 6:13 AM, Torsten Lodderstedt wrote:
Hi Andre,

I would expect the AS to treat a client with a different client id as =
another client. So the new client should not be able to use the "old" =
refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. =
Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of =
having a secret for the type of client you described (see Spec section =
10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don=92t see a strong reason to standardize behaviour here.  But it =
seems like a change in scope after a client upgrade is a good reason to =
expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any =
client update. But I think that unless there is a critical security due =
to the nature of the client and/or server, there is no reason to assume =
it is necessary beyond =93good practice=94.

One good reason for expiring tokens is that you are forcing the client =
to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and =
authentication system might inspect browser cookies that hold the =
previous SSO state and/or previous authorization state.  Thus you could =
avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, Andr=E9 DeMarre <andredemarre@gmail.com> =
wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

Hi Andre,

I would expect the AS to treat a client with a different client id as =
another client. So the new client should not be able to use the "old" =
refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. =
Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of =
having a secret for the type of client you described (see Spec section =
10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil =
Hunt <phil.hunt@oracle.com>:

I don=92t see a strong reason to standardize behaviour here.  But it =
seems like a change in scope after a client upgrade is a good reason to =
expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any =
client update. But I think that unless there is a critical security due =
to the nature of the client and/or server, there is no reason to assume =
it is necessary beyond =93good practice=94.

One good reason for expiring tokens is that you are forcing the client =
to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and =
authentication system might inspect browser cookies that hold the =
previous SSO state and/or previous authorization state.  Thus you could =
avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, Andr=E9 =
DeMarre <andredemarre@gmail.com> =
wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

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

Hi George,

if you want to effectively preseve the refresh token, why doesn't the AS just treat the new client id as an alias of the the old client id?

regards,
Torsten.

-------- Ursprüngliche Nachricht --------
Von: George Fletcher <gffletch@aol.com> 
Datum:03.04.2014  15:43  (GMT+01:00) 
An: Torsten Lodderstedt <torsten@lodderstedt.net>,Phil Hunt <phil.hunt@oracle.com> 
Cc: OAuth WG <oauth@ietf.org> 
Betreff: Re: [OAUTH-WG] Handling stored tokens in mobile app after software update with client credential change 

Hi Torsten,

We actually have the same issue. Deployed clients in the field where we want to update the client_id and doing so invalidates the existing refresh_token stored with the client. From a user experience perspective, this is a pain and from a risk perspective I think it's fine to effectively do a "token exchange" from the old refresh_token to the new one (with the appropriate security considerations in mind).

Andre got me thinking about this and here is what I'm leaning towards implementing in our system.

Use the JWT Client Assertion flow requesting an authorization grant for the existing user. The JWT would contain an "iss" of the new client_id, a "sub" of the userid the client should already know about, an "aud" of the Authorization Server, a short lived "exp" value as this is effectively a one-time token exchange, and an additional claim of the old refresh_token. Maybe an additional claim with the old client_id as well (still thinking about that as the client_id is already associated with the refresh_token).

This allows the AS to do the following checks...
1. Make sure the assertion is being presented by the new client (the level of surety is based on the risk associated with the client. If the client is provisioned with additional keys some how that's much stronger than just using a client_secret which, as you point out, doesn't really prove anything).
2. Verify that the "sub" value in the JWT is the same as that identified by the refresh_token
3. Verify that the client_id defined as the "issuer" is allowed to make this token exchange call and that the client_id in the refresh_token is one of those being replaced
4. Verify the audience of the JWT

If all the checks pass, then a new refresh_token can be issued, with exactly the same scopes as the "old" refresh_token (no ability in this flow to change scopes). The semantics of the refresh_token (e.g. authN time, expiry time, etc) need to be copied to the new refresh_token. In other words there should be no way to "extend" the lifetime of the refresh_token via this mechanism. It's purely a token exchange to provide a new refresh_token mapped to the new client_id.

Interested in feedback as to the viability of this.

Phil, I agree this doesn't need to be standardized, and I would like to see the community start collecting some "best practices" to help others that come across the same use case. It will ensure       a more secure internet for all of us.

Thanks,
George

On 4/3/14, 6:13 AM, Torsten Lodderstedt wrote:
Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.

One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

Hi Andre,

I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the "old" refresh tokens.

Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to bother
- public client means w/o secret - there is no security benefit of having a secret for the type of client you described (see Spec section 10)

Regards,
Torsten.

Am 03.04.2014 um 00:51 schrieb Phil Hunt <phil.hunt@oracle.com>:

I don’t see a strong reason to standardize behaviour here.  But it seems like a change in scope after a client upgrade is a good reason to expire existing tokens and re-authorize as well as simply expire tokens.

Some may choose to be very conservative and always expire tokens on any client update. But I think that unless there is a critical security due to the nature of the client and/or server, there is no reason to assume it is necessary beyond “good practice”.

One good reason for expiring tokens is that you are forcing the client to re-confirm it has the new client credential and it is still valid.

If you revoke tokens and refresh tokens, your authorization and authentication system might inspect browser cookies that hold the previous SSO state and/or previous authorization state.  Thus you could avoid re-authenticating the user and simply ask about the new scopes.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On Apr 2, 2014, at 1:37 PM, André DeMarre <andredemarre@gmail.com> wrote:

We have a mobile app which operates as an OAuth 2.0 public client
(w/client credentials). It uses the resource owner password
credentials grant type for authorized communication with our resource
servers.

We are working on a software update and want to change the registered
client_id and client_secret for the new app version (register a new
client at the auth server). The problem is that after the app updates
on users' devices, it will inherit the app data of the previous
version, including the access and refresh tokens.

Since the token scope issued to the new client might be different, we
know that we want the new app version to discard the previous
version's access tokens. But what about the refresh token?
Technically, the new version of the app will be a different client,
but the core OAuth spec section 6 says "the refresh token is bound to
the client to which it was issued." So what should we do?

We can program the app to discard the previous version's refresh
token, but that would inconvenience our users to re-enter their
password after the software update.

I'm tempted to allow the new client to use the refresh token issued to
the previous client, but that violates the spec.

Does the OAuth community have any insight here? Thank you.

Kind Regards,
Andre DeMarre

_______________________________________________
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

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

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

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

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

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

Hi all,

here are a few comments regarding the draft-ietf-oauth-dyn-reg-16 spec.
The first two are editorial and a matter of taste.

- Abstract

The abstract is awfully short. Could you at least add a few more lines
to tell the reader what to expect in the document?
- Introduction

I believe the problem statement in the introduction section could be a
bit clearer. I would phrase the story as follows: today client software
developers need to manually interact with a deployment organization to
obtain relevant parameters for their client software and/or to provide
meta-data about it. This can be time-consuming. This document provides a
mechanism for dynamically provisioning this information.
- Terminology

Please avoid RFC 2119 language in the terminology section. I also
believe it is unnecessary, for example in the client instance definition.
There is a bit of inconsistency in the terminology when I look at the
client software - client instance and the software api publisher -
software api deployment relationship. I would have expected to see
software api instance - software api publisher.

It might help readers to provide a few examples to show typical
relationships.

For example, a social network site (=deployment organization) develops
their own social network software and makes it available to application
developers. They are also a software API publisher and use OAuth to
protect access to the data. A software developer writes a client
software for use with the social network site and distributes different
client instances to smart phones.
I wonder whether it would make sense to use a different name for the
'initial access token', such as registration token to make it easier to
differentiate it from a regular access token. (Later in my review I will
argue that this access token is a bit strange...)

In the text you use the term 'client' but the terminology section only
defines 'client instance' and 'client software'. Does the term 'client'
refer to 'client software'?
- Protocol Flow

In Figure 1 you show the client and the developer in the same box. The
protocol defined in the specification clearly runs between a client and
client registration endpoint at an authorization server. So, I would
suggest to put the developer (which is a human) outside the box and to
draw another box around the client registration endpoint to indicate
that this is part of the authorization server.
- Section 2

What exactly does this sentence mean?

"
   Authorization servers MUST accept all fields in this list.
"

I believe I cannot mean that the authorization server supports all
mechanisms.

You write:

"
   Client metadata values can either be communicated directly in the
   body of a registration request, as described in Section 4.1, or
   included as claims in a software statement, as described in
   Section 3.  If the same client metadata name is present in both
   locations, the value in the software statement SHOULD take
   precedence.
"

It might be worthwhile to note that the two options exist to allow (a)
the client to suggest values and (b) to have the organizing issuing the
software assertion to provide further values.
Regarding the SHOULD in the last sentence I guess it might make more
sense to just say that it is deployment dependent what policy is used.
- Section 2.1

You write:

"
As such, a server supporting these fields
   SHOULD take steps to ensure that a client cannot register itself into
   an inconsistent state.
"

Any guidance on how the authorization server would do that?
- Section 3

I don't understand this sentence:

"
  In some cases, authorization servers MAY choose to accept a software
   statement value directly as a Client ID in an authorization request,
   without a prior dynamic client registration having been performed.
"

Does this mean that the client id is the software statement or that the
software statement is embedded in the client id or something else?
- Section 4

The story around the initial access token is a bit strange. Here is the
text:

   The client registration endpoint MAY be an OAuth 2.0 protected
   resource and accept an initial access token in the form of an OAuth
   2.0 [RFC6749] access token to limit registration to only previously
   authorized parties.  The method by which the initial access token is
   obtained by the registrant is generally out-of-band and is out of
   scope for this specification.  The method by which the initial access
   token is verified and validated by the client registration endpoint
   is out of scope for this specification.

First, the term 'registrant' is used here for the first time. Then, it
is outside the scope of how the client got this initial access token.
Normally for access tokens the client does not have to care about the
content and does not verify anything but here the last sentence hints to
the verification (although it is outside the scope of how it is used).

I am curious whether the software assertion could actually be re-use
here in case the unauthorized use of the registration by clients is a
concern!?
- Section 4.2

You write:

"
 This client identifier MUST be
   unique at the server and MUST NOT be in use by any other client.
"

This is a bit unclear given the text you provide in the subsequent
section, Section 5.1.
You write:

"
  client_id  REQUIRED.  Unique client identifier.  It MUST NOT be
      currently valid for any other distinct registered client.  It MAY
      be the same as the Client ID value used by other instances of this
      client, provided that the Redirection URI values and potentially
      other values dictated by authorization server policy are the same
      for all instances.
"
You write:

"
If a software statement was used as part of the registration, its
   value SHOULD be returned in the response and its value MUST be
   returned if the authorization server supports registration management
   operations [OAuth.Registration.Management] that would require its
   presence in subsequent operations.
"

I am not sure I understand that. Are you saying that the software
assertion is returned in the response from the authorization server to
the client? Why is that?
- References

I believe you should delete the dependency on the registration
management specification.

Ciao
Hannes

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

Hi all,

I read through the document as part of my shepherding task; it is nicely
written and easy to understand.

I only have a few minor suggestions:

* client_uri: URL of the homepage of the client.

Would it be better to say that this is the URI provides further
information about the client software (provided by the client software
developer)?
* logo_uri: The value of this field MUST point to a valid image file.

Would it make sense to provide a type field here as well, such as in
HTML (e.g., type="image/png")?
* contacts: Would these email addresses be in the format of
mailto:user@example.com or would you just use joe@example.com?
I am asking because with the URI scheme one could potentially provide
other contact information here as well, such as XMPP URIs or so.
* policy_uri: Would it be better to call this a privacy notice rather
than policy document?
Here is a short description what a privacy notice is:
https://www.privacyassociation.org/resource_center/privacy_glossary/privacy_notice
* jwks_uri: The text provides little information about how this element
is used. I believe that this is an alternative way of using the PoP
architecture, where the client registers keys with the authorization
server that can then be tied to access tokens. Right? I could add some
text in the PoP overview document to explain this and maybe you could
include a reference to the PoP document (as an informative reference,
for example).

Ciao
Hannes

_______________________________________________
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

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-meta=
data-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

____________________________________=
___________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-meta=
data-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-meta=
data-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

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