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

[Bill Mills <[e-mail]>]

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 <[e-mail]> wrote:
 


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

> Hi John, All,
> On 03/07/14 23:02, John Bradley wrote:
>> 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.
>> 
> 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.
> 
>> 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.
>> 
> 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.


> 
> Thanks, Sergey
> 
>> John B.
>> 
>> On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin <[e-mail]> wrote:
>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> -bill
>>>> 
>>>> 
>>>> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
>>>> <[e-mail]> wrote:
>>>> 
>>>> 
>>>> 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 <[e-mail]
>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail] <mailto:[e-mail]>>> 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:[e-mail]
>>>> <mailto:[e-mail]>]
>>>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM
>>>>>> *To:*Madjid Nakhjiri
>>>>>> *Cc:*[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>>> <mailto:[e-mail]>>
>>>>>> *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 <[e-mail]
>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>> 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
>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>>> <mailto:[e-mail]>>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>