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.

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. 
The spec is silent on the exact programming method that the Authorization server uses.

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.

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.nakhjiri@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
> https://www.ietf.org/mailman/listinfo/oauth