Re: [OAUTH-WG] refresh tokens and client instances
Bill Mills <wmills_92105@yahoo.com> Mon, 07 July 2014 21:17 UTC
Return-Path: <wmills_92105@yahoo.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0111B290F for <oauth@ietfa.amsl.com>; Mon, 7 Jul 2014 14:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.15
X-Spam-Level:
X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD7TP6WDxyAY for <oauth@ietfa.amsl.com>; Mon, 7 Jul 2014 14:17:45 -0700 (PDT)
Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C705B1B28B5 for <oauth@ietf.org>; Mon, 7 Jul 2014 14:17:44 -0700 (PDT)
Received: from [98.139.215.140] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jul 2014 21:17:43 -0000
Received: from [98.139.212.210] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jul 2014 21:17:43 -0000
Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 07 Jul 2014 21:17:43 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 900957.3398.bm@omp1019.mail.bf1.yahoo.com
Received: (qmail 70050 invoked by uid 60001); 7 Jul 2014 21:17:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404767863; bh=I/FjZwVYvHMkofNpMpGENmpWEl2M0LqktMoizH7w9vQ=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Apr11hT69dpekyrZ8lDXqFaDpBxjoiJyBFHllDeKDSFw5LaFMFHuGIKmFZLekK3QZ1AOVwYRcyX4E/ap0aTOd+qD7gm17hU4aZoRaB7DS756NHa0lN9Ex07xq0rpgjP1rIYsd87EY6w0uO828BdFsKxyCVroDbYS/RKUWedwM9c=
X-YMail-OSG: hclQb3EVM1l.E1JudDPANEO473CXTlRiDMK2_LHTqORk6Z_ VlL5g85pqQSA0obixpbb_W9iDEWmXYanaYPAIhDDwvcOG8HNlEbdt8rduouS fXMy6s6V2CH8Y2ZKZDtDmBl0J_sBMJ64waG9PhtMccdnjQqSQPikH7Vug2FW Z.UEwVF82wLMl0qgbZYTOR9rCpIWFeBNZaqI.OuqS.XPCe4peqkkDPfX7prh bN9_SNlK9V21lnWdG09Mmnat1RTO80v8QcSdsS4nDnuXaitatqk.Ji3yRE9N yzTbiQ_bxkRrP_j8caYD0WlmpHcEoBPXjDLmrgIB4Xv2cqxxbkZyHJ5J2vRv 3_ImnOMhDi.nx5X7WCFP7n27oVQy1aQteNFlbLw7mX._lI3D3tZQoUA5qbUd kAgkuxQLHmtt5kLwgwcxZmI3NSuEcQ7PjfQXJe.h4uSFEJeLFYfBPqFYMCag KVLyH00q0Y3wkQ_Dd0bzAc6Ey9h_rem.433IXtRfZKx9TS7jJoZOmRdn6JYO X5NRnjzgCyduluqc.N1wOjqX5Z2or5sap2P_scOSJyeEF4HCrXg--
Received: from [167.220.24.190] by web142806.mail.bf1.yahoo.com via HTTP; Mon, 07 Jul 2014 14:17:43 PDT
X-Rocket-MIMEInfo: 002.001, SSB3b3VsZCBhcmd1ZSB0aGF0IGlmIHRoZSB1c2VyIGFwcHJvdmVkIGEgc3BlY2lmaWMgYWNjZXNzIHByb2ZpbGUgdGhhdCB0aGUgdG9rZW4gc2hvdWxkIGJlIGxpbWl0ZWQgdG8gdGhhdC4gwqBJZiBpdCB3YW50cyBtb3JlIHJpZ2h0cy9zY29wZSB0aGF0IHNob3VsZCB0cmlnZ2VyIGFuIGFwcHJvdmFsIGZyb20gdGhlIHVzZXIgYmFzZWQgb24gYSBmdWxsIGF1dGhlbnRpY2F0aW9uLiDCoEl0J3MgYWxsIGEgYml0IG11ZHkgdGhvdWdoIGJlY2F1c2UgeW91IGNvdWxkIGltYWdpbmUgaW1wbGVtZW50aW5nIGEgbW8BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.191.1
References: <007a01cf90d2$7bdda950$7398fbf0$%nakhjiri@samsung.com> <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com> <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com> <EF0302C0-8077-408D-B82B-35FEAFD3C263@ve7jtb.com> <53B53F7C.506@gmail.com> <1404402057.15252.YahooMailNeo@web142801.mail.bf1.yahoo.com> <53B584BA.6090901@gmail.com> <38EB3E9D-BA98-4A48-89A7-48C57F501238@ve7jtb.com> <53BB0A20.6020009@gmail.com> <F5D64618-7EBF-489E-9E1B-43B1D0DB1740@ve7jtb.com>
Message-ID: <1404767863.61837.YahooMailNeo@web142806.mail.bf1.yahoo.com>
Date: Mon, 07 Jul 2014 14:17:43 -0700
From: Bill Mills <wmills_92105@yahoo.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Sergey Beryozkin <sberyozkin@gmail.com>
In-Reply-To: <F5D64618-7EBF-489E-9E1B-43B1D0DB1740@ve7jtb.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="515012262-783076836-1404767863=:61837"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3nZdJKt0me-nLJdtE03i5Q_4soo
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] refresh tokens and client instances
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <wmills_92105@yahoo.com>
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 21:17:54 -0000
I would argue that if the user approved a specific access profile that the token should be limited to that. If it wants more rights/scope that should trigger an approval from the user based on a full authentication. It's all a bit mudy though because you could imagine implementing a more limited scope the user would not have to approve. On Monday, July 7, 2014 2:09 PM, John Bradley <ve7jtb@ve7jtb.com> wrote: Inline On Jul 7, 2014, at 4:59 PM, Sergey Beryozkin <sberyozkin@gmail.com> 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 <sberyozkin@gmail.com> 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 >>>> <sberyozkin@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.nakhjiri@samsung.com >>>> <mailto:m.nakhjiri@samsung.com> >>>>> <mailto:m.nakhjiri@samsung.com <mailto:m.nakhjiri@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:ve7jtb@ve7jtb.com >>>> <mailto:ve7jtb@ve7jtb.com>] >>>>>> *Sent:*Wednesday, June 25, 2014 5:56 PM >>>>>> *To:*Madjid Nakhjiri >>>>>> *Cc:*oauth@ietf.org <mailto:oauth@ietf.org> <mailto: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.nakhjiri@samsung.com >>>> <mailto:m.nakhjiri@samsung.com> >>>>>> <mailto:m.nakhjiri@samsung.com <mailto: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 <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >>>> <mailto:OAuth@ietf.org>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> _______________________________________________ >>>> 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-WG] refresh tokens and client instances Madjid Nakhjiri
- Re: [OAUTH-WG] refresh tokens and client instances John Bradley
- Re: [OAUTH-WG] refresh tokens and client instances Madjid Nakhjiri
- Re: [OAUTH-WG] refresh tokens and client instances John Bradley
- Re: [OAUTH-WG] refresh tokens and client instances Madjid Nakhjiri
- Re: [OAUTH-WG] refresh tokens and client instances Sergey Beryozkin
- Re: [OAUTH-WG] refresh tokens and client instances Bill Mills
- Re: [OAUTH-WG] refresh tokens and client instances Sergey Beryozkin
- Re: [OAUTH-WG] refresh tokens and client instances Bill Mills
- Re: [OAUTH-WG] refresh tokens and client instances John Bradley
- Re: [OAUTH-WG] refresh tokens and client instances Sergey Beryozkin
- Re: [OAUTH-WG] refresh tokens and client instances John Bradley
- Re: [OAUTH-WG] refresh tokens and client instances Madjid Nakhjiri
- Re: [OAUTH-WG] refresh tokens and client instances Bill Mills
- Re: [OAUTH-WG] refresh tokens and client instances Sergey Beryozkin
- Re: [OAUTH-WG] refresh tokens and client instances John Bradley
- Re: [OAUTH-WG] refresh tokens and client instances John Bradley