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 <sberyoz...@gmail.com>
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 <m.nakhj...@samsung.com
> <mailto:m.nakhj...@samsung.com>> 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:ve7...@ve7jtb.com]
>> *Sent:*Wednesday, June 25, 2014 5:56 PM
>> *To:*Madjid Nakhjiri
>> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org>
>> *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 <m.nakhj...@samsung.com
>> <mailto:m.nakhj...@samsung.com>> 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
>> OAuth@ietf.org <mailto: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
