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

[Sergey Beryozkin <[e-mail]>]

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 ?

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

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
>