Subject: Re: [OAUTH-WG] refresh tokens and client instances

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 03 Jul 2014 12:33:16 +0100

Hi

I'm finding the answers from John interesting but I'm failing to 
understand why refresh tokens are mentioned in scope of identifying the 
specific client instances.

AFAIK refresh tokens would only go on the wire, assuming they are 
supported, when a client exchanges a grant for a new access token.
And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id 
and refresh token pair can uniquely identify the actual client instance 
? That would make sense.

Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant 
initialization time. Would it make any difference, as far as the 
security properties of a grant are concerned, if refresh token was only 
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:
> Inline
>
> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi John,
>> Thank you for your reply. Would appreciate if you consider my inline
>> comments below and respond again!
>> R,
>> Madjid
>> *From:*John Bradley [mailto:[email-masked]]
>> *Sent:*Wednesday, June 25, 2014 5:56 PM
>> *To:*Madjid Nakhjiri
>> *Cc:[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
>> In 3.3 It is saying that the refresh token is a secret that the
>> Authorization server has bound to the client_id, that the
>> Authorization server effectively uses to differentiate between
>> instances of that client_id.
>> Madjid>>If I have 10,000s of devices, each with an instance of the
>> OAUTH client, but they are all using the same client ID, how would the
>> server know which token to use for what client? unless when I am
>> creating a token, I also include something that uniquely identifies
>> each instance? Don’t I have to use SOMETHING that is unique to that
>> instance (user grant/ID?)?
> When the grant is issued you create and store a refresh token which is
> effectively the identifier for that instance/grant combination.
> When it comes back on a request to the token endpoint you look up the
> grants associated with it.   You also hack that the client_id sent in
> the request matches to detect errors mostly)
>
>> When the refresh token is generated, it can be stored in a table with
>> the client_id and the information about the grant.   You could also do
>> it statelesly by creating a signed object as the refresh token.
>> Madjid>>agreed, but for the signed object to be self-sustained, again
>> would I not need something beyond a “population” client_ID? Are we
>> prescriptive what “information about the grant” is?
> You would be creating a bearer token as long as the AS signs it you can
> put whatever grant grant info you like in it, that is implementation
> specific.  It  could be a list of the scopes granted and the subject.
>> The spec is silent on the exact programming method that the
>> Authorization server uses.
>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?)
>> that prescribe token calculation (e.g. hash function, parameters, etc)?
>
> You can look at JOSE and JWT for a way to create tokens
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
>> In 3.7 Deployment independent describes using the same client_id
>> across multiple instances of a native client, or multiple instances of
>> a Java Script client running in a browsers with the same callback uri.
>> Since the publishing of this RFC we have also developed a spec for
>> dynamic client registration so it is possible to give every native
>> client it's own client_id and secret making them confidential clients.
>> Madjid>>I would need to look at those specs, however, I thought that
>> the “confidential client” designation has to do with the client
>> ability to hold secrets and perform a-by-server-acceptable
>> authentication. Does dynamic client registration affect client’s
>> ability in that aspect?
>
> Yes it doesn't require the secret to be in the downloaded instance of
> the native app.  It can be populated at first run, changing it from
> public to confidential.
> Confidential is not just for web servers any more.
>> There is also a middle ground some people take by doing a proof of
>> possession for code in native applications to prevent the interception
>> of responses to the client by malicious applications on the device.
>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
>> John B.
>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>> Hi all,
>> I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.
>> I am evaluating an OAUTH 2.0 implementation that is done based on bare
>> bone base OAUTH2.0 RFC. From what I understand, many (or some) client
>> implementations use a “global ID/secret” pair for all instances of the
>> client.  Looking at RFC 6819 and there seem to be a whole page on this
>> topic, if I understand it correctly. So questions:
>> 1)Section 3.7 talks about deployment-independent versus deployment
>> specific client IDs. I am guessing “deployment-independent” refers to
>> what I called “global”, meaning if I have the same client with the
>> same client ID installed in many end devices, that is a deployment
>> independent case, correct?
>> 2)Section 3.3 on refresh token mentions that the token is secret bound
>> to the client ID and client instance. Could somebody please point me
>> to where the token generation and binding is described? Also how is
>> the client instance is identified?
>> Thanks a lot in advance,
>> Madjid Nakhjiri
>> _______________________________________________
>> OAuth mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Bill Mills <[email-masked]>
Date: Thu, 3 Jul 2014 08:40:57 -0700

Implementations may/SHOULD bind refresh tokens to specific client instances.  Yes, it's possible that the client ID with dynamic registration is unique to each client, but many of the token theft use cases include the possibility of stealing the client ID too if you know you need to.

-bill

On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin <[email-masked]> wrote:

Hi

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 03 Jul 2014 17:28:42 +0100

Hi
On 03/07/14 16:40, Bill Mills wrote:
> Implementations may/SHOULD bind refresh tokens to specific client
> instances.  Yes, it's possible that the client ID with dynamic
> registration is unique to each client, but many of the token theft use
> cases include the possibility of stealing the client ID too if you know
> you need to.
>
What exactly is a 'client instance' when we talk about having a single 
client id registration, with the id shared between multiple devices 
(which is what I believe this thread started from).

What I understood, as far as the authorization service is concerned, a 
'client instance' for AS is a combination of a client id + code grant.

+ (optional) refresh token (as was mentioned earlier). But it appears to 
me a client instance can be uniquely identified by two values only 
without a refresh token.

When a user authorizes a given device and gets a grant code and enters 
it into the device securely we have a 'client instance' ready to get the 
tokens, with that device (client instance) using a client id and the 
grant code to get an access token and a refresh token.

Lets say it sends a "client_id=1&code=2" sequence to get the tokens.
A client id + a code value constitutes a client instance, because a code 
would be unique per every authorization, right ?

So the service will return an access token + refresh token to the 
device. Refresh Token could've been associated with a record containing 
a client id + grant code info earlier or at the moment the code is 
exchanged for an access token.

During the subsequent refresh token grant request we have "client id + 
refresh token" as a client instance.

I'm not sure what exactly I'd like to ask here :-), but I wonder if the 
above sounds right, then I guess I'd like to conclude that when we talk 
about the authorization code grant then a refresh token is not the only 
key that uniquely identifies a client instance:

Initially it is a client id + code grant, a refresh token does not offer 
an extra uniqueness at the point of the client device requesting an 
access token with a code. Refresh token only starts acting as the key 
client instance identifier at a refresh token grant time.

Sorry for a long email, I'm very likely missing something, so any 
clarifications will be welcome

Thanks, Sergey

> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >
>  >> Hi John,
>  >> *From:*John Bradley [mailto:[email-masked]
> <mailto:[email-masked]>]
>  >> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
> <mailto:[email-masked]>
>  >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >>
>  >>
>  >> Hi all,
>  >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: Bill Mills <[email-masked]>
Date: Thu, 3 Jul 2014 10:14:36 -0700

You might have a public client, the Flickr client for example (which uses OAuth 1 right now but it's a useful example) where the client ID is baked into the install.  In this case binding the token to the client ID means only that someone who steals the token and tries to use it with a different client ID would fail.

With DynReg that client could generate a nonce and include it in a dynamically registered client ID and then the credential could be bound to that specific software instance.

A 3rd possibility is multiple clients on a device sharing the same auth context, in which case they all use the same library perhaps and so several installed apps all would share the same "client id" from the servers perspective (the one for the auth API) but they might each get different scopes.

On Thursday, July 3, 2014 9:28 AM, Sergey Beryozkin <[email-masked]> wrote:

Hi

Thanks, Sergey

>  > Inline
>  >
>  > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri <[email-masked]
>  > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >
>  >> Hi John,
>  >> Thank you for your reply. Would appreciate if you consider my inline
>  >> comments below and respond again!
>  >> R,
>  >> Madjid
>  >> *From:*John Bradley [mailto:[email-masked]
>  >> *Sent:*Wednesday, June 25, 2014 5:56 PM
>  >> *To:*Madjid Nakhjiri
>  >> *Cc:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  >> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
>  >> In 3.3 It is saying that the refresh token is a secret that the
>  >> Authorization server has bound to the client_id, that the
>  >> Authorization server effectively uses to differentiate between
>  >> instances of that client_id.
>  >> Madjid>>If I have 10,000s of devices, each with an instance of the
>  >> OAUTH client, but they are all using the same client ID, how would the
>  >> server know which token to use for what client? unless when I am
>  >> creating a token, I also include something that uniquely identifies
>  >> each instance? Don’t I have to use SOMETHING that is unique to that
>  >> instance (user grant/ID?)?
>  > When the grant is issued you create and store a refresh token which is
>  > effectively the identifier for that instance/grant combination.
>  > When it comes back on a request to the token endpoint you look up the
>  > grants associated with it.  You also hack that the client_id sent in
>  > the request matches to detect errors mostly)
>  >
>  >> When the refresh token is generated, it can be stored in a table with
>  >> the client_id and the information about the grant.  You could also do
>  >> it statelesly by creating a signed object as the refresh token.
>  >> Madjid>>agreed, but for the signed object to be self-sustained, again
>  >> would I not need something beyond a “population” client_ID? Are we
>  >> prescriptive what “information about the grant” is?
>  > You would be creating a bearer token as long as the AS signs it you can
>  > put whatever grant grant info you like in it, that is implementation
>  > specific.  It  could be a list of the scopes granted and the subject.
>  >> The spec is silent on the exact programming method that the
>  >> Authorization server uses.
>  >> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?)
>  >> that prescribe token calculation (e.g. hash function, parameters, etc)?
>  >
>  > You can look at JOSE and JWT for a way to create tokens
>  > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
>  >> In 3.7 Deployment independent describes using the same client_id
>  >> across multiple instances of a native client, or multiple instances of
>  >> a Java Script client running in a browsers with the same callback uri.
>  >> Since the publishing of this RFC we have also developed a spec for
>  >> dynamic client registration so it is possible to give every native
>  >> client it's own client_id and secret making them confidential clients.
>  >> Madjid>>I would need to look at those specs, however, I thought that
>  >> the “confidential client” designation has to do with the client
>  >> ability to hold secrets and perform a-by-server-acceptable
>  >> authentication. Does dynamic client registration affect client’s
>  >> ability in that aspect?
>  >
>  > Yes it doesn't require the secret to be in the downloaded instance of
>  > the native app.  It can be populated at first run, changing it from
>  > public to confidential.
>  > Confidential is not just for web servers any more.
>  >> There is also a middle ground some people take by doing a proof of
>  >> possession for code in native applications to prevent the interception
>  >> of responses to the client by malicious applications on the device.
>  >> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
>  >> John B.
>  >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri <[email-masked]
>  >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >>
>  >>
>  >> Hi all,
>  >> I am new to OAUTH list and OAUTH, so apologies if this is very
> off-topic.
>  >> I am evaluating an OAUTH 2.0 implementation that is done based on bare
>  >> bone base OAUTH2.0 RFC. From what I understand, many (or some) client
>  >> implementations use a “global ID/secret” pair for all instances of the
>  >> client.  Looking at RFC 6819 and there seem to be a whole page on this
>  >> topic, if I understand it correctly. So questions:
>  >> 1)Section 3.7 talks about deployment-independent versus deployment
>  >> specific client IDs. I am guessing “deployment-independent” refers to
>  >> what I called “global”, meaning if I have the same client with the
>  >> same client ID installed in many end devices, that is a deployment
>  >> independent case, correct?
>  >> 2)Section 3.3 on refresh token mentions that the token is secret bound
>  >> to the client ID and client instance. Could somebody please point me
>  >> to where the token generation and binding is described? Also how is
>  >> the client instance is identified?
>  >> Thanks a lot in advance,
>  >> Madjid Nakhjiri
>  >> _______________________________________________
>  >> OAuth mailing list
>  >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  >> https://www.ietf.org/mailman/listinfo/oauth
>
>  >
>  >
>  >
>  > _______________________________________________
>  > OAuth mailing list
>  > [email-masked] <mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/oauth

>  >

---

From: John Bradley <[email-masked]>
Date: Thu, 3 Jul 2014 18:02:58 -0400

Yes,

The the undifferentiated is initially differentiated by the user during Authorization by having a code returned and then by exchanging the code for a refresh token.
It however returns to being undifferentiated on subsequent authorization requests.    
This makes having sticky grants (only asking for permission for incremental scopes) a potential security problem, as the AS has no way to know if the client is the one that the pervious authorization was intended for. 

Some AS just assume that you want the same permissions across all instances of a client,  however if this is a public client then someone could impersonate the client app and basically do privilege escalation.

What dynamic client registration gives us for native apps is a way to identify specific instances of clients at the authorization endpoint by having different client_id and validating that with instance specific client credentials.  This also prevents the use of code if it is intercepted in the reply from the authorization endpoint.

John B.

On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin <[email-masked]> wrote:

> What exactly is a 'client instance' when we talk about having a single client id registration, with the id shared between multiple devices (which is what I believe this thread started from).
> 
> What I understood, as far as the authorization service is concerned, a 'client instance' for AS is a combination of a client id + code grant.
> 
> + (optional) refresh token (as was mentioned earlier). But it appears to me a client instance can be uniquely identified by two values only without a refresh token.
> 
> When a user authorizes a given device and gets a grant code and enters it into the device securely we have a 'client instance' ready to get the tokens, with that device (client instance) using a client id and the grant code to get an access token and a refresh token.
> 
> A client id + a code value constitutes a client instance, because a code would be unique per every authorization, right ?
> 
> So the service will return an access token + refresh token to the device. Refresh Token could've been associated with a record containing a client id + grant code info earlier or at the moment the code is exchanged for an access token.
> 
> During the subsequent refresh token grant request we have "client id + refresh token" as a client instance.
> 
> I'm not sure what exactly I'd like to ask here :-), but I wonder if the above sounds right, then I guess I'd like to conclude that when we talk about the authorization code grant then a refresh token is not the only key that uniquely identifies a client instance:
> 
> Initially it is a client id + code grant, a refresh token does not offer an extra uniqueness at the point of the client device requesting an access token with a code. Refresh token only starts acting as the key client instance identifier at a refresh token grant time.
> 
> Sorry for a long email, I'm very likely missing something, so any clarifications will be welcome
> 
> Thanks, Sergey
> 
> 
> 
> 
> 
> 
> 
>> -bill
>> 
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 07 Jul 2014 21:59:12 +0100

Hi John, All,
> Some AS just assume that you want the same permissions across all instances of a client,  however if this is a public client then someone could impersonate the client app and basically do privilege…
Why would a public client holding a refresh token securely entered into 
it by a user request a new authorization without actually requesting the 
new scopes ? The client can just get a new access/refresh token from now 
on ?

> What dynamic client registration gives us for native apps is a way to identify specific instances of clients at the authorization endpoint by having different client_id and validating that with ins…
Would it be fair to say that a dynamic client registration is a 
preferred method of registering *public* clients from now on, *unless*
no sticky grants are used in which case a typical/default registration 
mode is OK ?

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Mon, 7 Jul 2014 17:09:26 -0400

Inline
On Jul 7, 2014, at 4:59 PM, Sergey Beryozkin <[email-masked]> wrote:

> Why would a public client holding a refresh token securely entered into it by a user request a new authorization without actually requesting the new scopes ? The client can just get a new access/refresh token from now on ?

A client holding a refresh token may want to add additional scopes, perhaps it only initially asked for permission to get a email address and now it wants a phone number.

If it is a public client the AS needs to ask for permission to grant both scopes,  it can't treat the email permission as sticky.
> Would it be fair to say that a dynamic client registration is a preferred method of registering *public* clients from now on, *unless*
> no sticky grants are used in which case a typical/default registration mode is OK ?

It is up to the AS and how it wants to manage clients.  Some will not want to manage thousands of client_id, others won't mind.  

If you don't have sticky grants and can mitigate code being intercepted in the response by using http://tools.ietf.org/html/draft-sakimura-oauth-tcse ,
then having a public client works.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 07 Jul 2014 14:17:38 -0700

Hi Sergey,

Thanks for capturing the question. Yes, the issue was how we distinguish between different instances of client, all using the same client ID. >From answers I have gotten so far, it seems that the uniqueness of the instance may be provided through the uniqueness of a code grant. However, I have not figure out what the spec says on how to create the grant and how the grant code is unique to authorization server. If anybody could point me to that part of spec, I would appreciate it (I did not find it). 

Your description of "a user authorizes a given device and gets a grant code and enters it into device securely we have a client instance..." would require a device identifier, otherwise how does the fact that the client is on a different device identifies that instance as a unique instance?

I need to look at the spec for refresh versus access tokens. Do you need different grant code types for each type of token?

Thanks,
Madjid
-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Sergey Beryozkin
Sent: Thursday, July 03, 2014 9:29 AM
To: Bill Mills; [email-masked]
Subject: Re: [OAUTH-WG] refresh tokens and client instances

Hi
On 03/07/14 16:40, Bill Mills wrote:
> cases include the possibility of stealing the client ID too if you 
> know you need to.
>

+ (optional) refresh token (as was mentioned earlier). But it appears to
me a client instance can be uniquely identified by two values only without a refresh token.

Thanks, Sergey

> understand why refresh tokens are mentioned in scope of identifying 
> the specific client instances.
>
> and refresh token pair can uniquely identify the actual client 
> instance ? That would make sense.
>
> security properties of a grant are concerned, if refresh token was 
> only created at a grant to access token exchange point of time ?
>
> Thanks, Sergey
>
>  > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri 
> <[email-masked] <mailto:[email-masked]>  > 
>  >> Thank you for your reply. Would appreciate if you consider my 
> inline  >> comments below and respond again!
>  >> R,
>  >> Madjid
> <mailto:[email-masked]>]  >> *Sent:*Wednesday, June 25, 2014 5:56 
> PM  >> *To:*Madjid Nakhjiri  >> *Cc:[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>  >> *Subject:*Re: [OAUTH-WG] refresh tokens 
> and client instances  >> In 3.3 It is saying that the refresh token is 
> a secret that the  >> Authorization server has bound to the client_id, 
> that the  >> Authorization server effectively uses to differentiate 
> between  >> instances of that client_id.
> >> OAUTH client, but they are all using the same client ID, how would 
> the  >> server know which token to use for what client? unless when I 
> am  >> creating a token, I also include something that uniquely 
> identifies  >> each instance? Don’t I have to use SOMETHING that is 
> unique to that  >> instance (user grant/ID?)?
>  > When the grant is issued you create and store a refresh token which 
> is  > effectively the identifier for that instance/grant combination.
>  > When it comes back on a request to the token endpoint you look up 
> the  > grants associated with it.  You also hack that the client_id 
> sent in  > the request matches to detect errors mostly)  >  >> When 
> the refresh token is generated, it can be stored in a table with  >> 
>  >> Madjid>>agreed, but for the signed object to be self-sustained, 
> again  >> would I not need something beyond a “population” client_ID? 
> Are we  >> prescriptive what “information about the grant” is?
>  > You would be creating a bearer token as long as the AS signs it you 
> can  > put whatever grant grant info you like in it, that is 
> implementation  > specific.  It  could be a list of the scopes granted and the subject.
>  >> The spec is silent on the exact programming method that the  >> 
>  >> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, 
> etc?)  >> that prescribe token calculation (e.g. hash function, parameters, etc)?
>  >
>  > You can look at JOSE and JWT for a way to create tokens  > 
> >> across multiple instances of a native client, or multiple instances 
> of  >> a Java Script client running in a browsers with the same callback uri.
>  >> Madjid>>I would need to look at those specs, however, I thought 
> that  >> the “confidential client” designation has to do with the 
> client  >> ability to hold secrets and perform a-by-server-acceptable  
>  > Yes it doesn't require the secret to be in the downloaded instance 
> of  > the native app.  It can be populated at first run, changing it 
> from  > public to confidential.
> >> possession for code in native applications to prevent the 
> interception  >> of responses to the client by malicious applications on the device.
>  >> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri 
> <[email-masked] <mailto:[email-masked]>  >> 
>  >> I am evaluating an OAUTH 2.0 implementation that is done based on 
> bare  >> bone base OAUTH2.0 RFC. From what I understand, many (or 
> some) client  >> implementations use a “global ID/secret” pair for all 
> instances of the  >> client.  Looking at RFC 6819 and there seem to be 
> a whole page on this  >> topic, if I understand it correctly. So questions:
> >> specific client IDs. I am guessing “deployment-independent” refers 
> to  >> what I called “global”, meaning if I have the same client with 
> the  >> same client ID installed in many end devices, that is a 
> deployment  >> independent case, correct?
>  >> 2)Section 3.3 on refresh token mentions that the token is secret 
> bound  >> to the client ID and client instance. Could somebody please 
> point me  >> to where the token generation and binding is described? 
> Also how is  >> the client instance is identified?
>  >> Thanks a lot in advance,
>  >> Madjid Nakhjiri
> <mailto:[email-masked]>>  >> 
>  > [email-masked] <mailto:[email-masked]>  >

---

From: Bill Mills <[email-masked]>
Date: Mon, 7 Jul 2014 14:17:43 -0700

I would argue that if the user approved a specific access profile that the token should be limited to that.  If it wants more rights/scope that should trigger an approval from the user based on a full authentication.  It's all a bit mudy though because you could imagine implementing a more limited scope the user would not have to approve.

On Monday, July 7, 2014 2:09 PM, John Bradley <[email-masked]> wrote:

Inline

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 07 Jul 2014 22:28:17 +0100

Hi John
Thanks, see inline
> If it is a public client the AS needs to ask for permission to grant both scopes,  it can't treat the email permission as sticky.
Sure I understand, I asked why would a client request the authorization 
without requesting new scopes. So basically, I'm trying to figure out 
where the value of the dynamic registration is - so it appears the 
'stickier' the grant the more valuable the dynamic registration becomes.

> then having a public client works.
OK.

Thanks for the comments, Sergey

---

From: John Bradley <[email-masked]>
Date: Mon, 7 Jul 2014 17:36:32 -0400

I was assuming re-authenticating the user.   The thing is that with a public client you can't assume that it is the same instance of that client that requested the first grant for email, so you really should re-prompt for both scopes.

I have seen instances (mostly OAuth 1) where a AS is sloppy and remembers persistent grants( sometimes including default ones for the venders own app).  
An attacker gets the client_id and app_secret and impersonates the app.  If a user has pre-consented to scopes the attacker can by impersonating the legitimate app get scopes that the user has not consented to.

In OAuth 2 attack can take advantage of AS that don't require registering redirect URI for the code flow,  because they mistakenly confuse code with confidential.

In my opinion you should not use sticky grants with clients that are not confidential, and dynamic registration lets you make a native app confidential.
(no you can't guarantee the app is legitimate without some sort of out of band verification, but it is confidential)

John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 7 Jul 2014 17:46:33 -0400

The client always needs a client_id.  

After the user authorizes the client the AS creates a code (there are lots of ways to do it, a database entry works for most people), and returns it to the client.

The client instance by possession  of that code is differentiated from other instances of that client in it's requests to the token endpoint by having a unique code or refresh_token.
That code and refresh token have grants associated with them for the user.

The user doesn't enter the code it is returned to the client in a query parameter appended to the redirect_uri.

The code is exchanged for a access token and optionally a refresh token,  after the access token expires the client can use the refresh token to get another access token. 
If the client doesn't have a refresh token it needs to go through authorization again.

John B.