Inline On Jul 7, 2014, at 4:59 PM, Sergey Beryozkin <[email protected]> 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. > >> 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. > > Thanks, Sergey > >> John B. >> >> On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin <[email protected]> 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 >>>> <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>>> 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:[email protected] >>>> <mailto:[email protected]>] >>>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM >>>>>> *To:*Madjid Nakhjiri >>>>>> *Cc:*[email protected] <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>> >>>>>> *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 <[email protected] >>>> <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>>> 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 >>>>>> [email protected] <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
