Re: [OAUTH-WG] refresh tokens and client instances
John Bradley <ve7jtb@ve7jtb.com> Mon, 07 July 2014 21:09 UTC
Return-Path: <ve7jtb@ve7jtb.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 766AB1B28E6 for <oauth@ietfa.amsl.com>; Mon, 7 Jul 2014 14:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 S0Qa7OmjwOo0 for <oauth@ietfa.amsl.com>; Mon, 7 Jul 2014 14:09:33 -0700 (PDT)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3812A1B28E1 for <oauth@ietf.org>; Mon, 7 Jul 2014 14:09:33 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id l6so4341838qcy.4 for <oauth@ietf.org>; Mon, 07 Jul 2014 14:09:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=s8UHPNbUlSU/vTbgCEDiuXDYDJghrgN1RXiSaq+Tmuw=; b=ev2uRZY6znFsl5PZao68cAuYxEOfHjkadNctLPyyJLvFd5rvJZ8UhEsqR2eLzUk7zs Mq0axKG2fAvoktu/kFXw4Z0Dag6KJ/pw0htT/kA23dLX6TMv+Goy8+y1Nk0TklaQODqT m7keqLr6Aa55m4FtrznVazbwPYL1s8GMNBRVvXgIHj8ZAbZYCsyBd2xBk6r2NXcbADom QNtSkxwKbXjkst9hmvMH1wJR6I+30KKp/RTQuM3dEHte6PCO6zqp0ZrEOf04X0nkMLBX QGsEr/5kgMgOr10b1jIY68AnV8x9n/+qrQlQzL+qgY8Qp44dGDZCgihKNr5l9TdnLuJO PUGg==
X-Gm-Message-State: ALoCoQlGA33WBdUNpelZUL0tkull4w/EHaFg2vARuOZW6yi4j9ATWpWfv1QFtoXljWZuI46BFeSt
X-Received: by 10.140.93.35 with SMTP id c32mr40246803qge.53.1404767372216; Mon, 07 Jul 2014 14:09:32 -0700 (PDT)
Received: from [192.168.0.200] ([201.188.84.221]) by mx.google.com with ESMTPSA id q10sm76481509qah.9.2014.07.07.14.09.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 14:09:31 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <53BB0A20.6020009@gmail.com>
Date: Mon, 07 Jul 2014 17:09:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5D64618-7EBF-489E-9E1B-43B1D0DB1740@ve7jtb.com>
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>
To: Sergey Beryozkin <sberyozkin@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Hk_758M4QboqstFbJjcVrO06Lso
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
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:09:36 -0000
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