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.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 > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
