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

[Sergey Beryozkin <[e-mail]>]

Hi John
Thanks, see inline
On 07/07/14 22:09, John Bradley 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.
>>
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.

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

Thanks for the comments, Sergey

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