Re: [OAUTH-WG] refresh tokens and client instances
Madjid Nakhjiri <m.nakhjiri@samsung.com> Sat, 28 June 2014 00:50 UTC
Return-Path: <m.nakhjiri@samsung.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 8ABF81A024F for <oauth@ietfa.amsl.com>; Fri, 27 Jun 2014 17:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.55
X-Spam-Level:
X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 xiy_TA6WkAS0 for <oauth@ietfa.amsl.com>; Fri, 27 Jun 2014 17:50:38 -0700 (PDT)
Received: from usmailout1.samsung.com (mailout1.w2.samsung.com [211.189.100.11]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842BC1A024B for <oauth@ietf.org>; Fri, 27 Jun 2014 17:50:38 -0700 (PDT)
Received: from uscpsbgm1.samsung.com (u114.gpu85.samsung.co.kr [203.254.195.114]) by mailout1.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N7U00G7NT0CTV50@mailout1.w2.samsung.com> for oauth@ietf.org; Fri, 27 Jun 2014 20:50:36 -0400 (EDT)
X-AuditID: cbfec372-b7fe76d00000687e-a7-53ae115ccf28
Received: from ussync3.samsung.com ( [203.254.195.83]) by uscpsbgm1.samsung.com (USCPMTA) with SMTP id 97.08.26750.C511EA35; Fri, 27 Jun 2014 20:50:36 -0400 (EDT)
Received: from sdsamadjidPC ([105.66.230.137]) by ussync3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0N7U00CKCT0BRW30@ussync3.samsung.com>; Fri, 27 Jun 2014 20:50:36 -0400 (EDT)
From: Madjid Nakhjiri <m.nakhjiri@samsung.com>
To: 'John Bradley' <ve7jtb@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>
In-reply-to: <EF0302C0-8077-408D-B82B-35FEAFD3C263@ve7jtb.com>
Date: Fri, 27 Jun 2014 17:50:37 -0700
Message-id: <005401cf926a$fab3a6a0$f01af3e0$%nakhjiri@samsung.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_0055_01CF9230.4E54CEA0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: Ac+SNGu01z+Kdj7CSS+uZ5xEc16qmQANmWVA
Content-language: en-us
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsVy+t/hYN0YwXXBBjNXGVucfPuKzWL13b9s DkweS5b8ZPK4fXsjSwBTFJdNSmpOZllqkb5dAldGz+4LbAU3NjBWTJi9hqmBcf0sxi5GDg4J AROJ85uDuhg5gUwxiQv31rN1MXJxCAksYZRo+f6KBcJpYZK4sPYeM0gVm4CexP55M8BsEQE1 ieXbO9lBbGYBIYkPl5qgGh4zSjS+7WADSXAK2El8ej0XzBYWsJZ4s+44WDOLgKrEvXermUBs XgEniekv2tggbEGJH5PvsUAMjZY4um4ZK8Sl6hKP/upC7DWSONDzhBGiRFxi0oOH7BMYBWch 6Z6FpHsWkrJZQJOYgV5o28gIEZaX2P52DjOErSvx/zmMrS2xbOFr5gWM7KsYRUuLkwuKk9Jz DfWKE3OLS/PS9ZLzczcxQiKiaAfjsw1WhxgFOBiVeHgbd60NFmJNLCuuzD3EKMHBrCTCq/wa KMSbklhZlVqUH19UmpNafIiRiYNTqoHRnf3CtQ28zAxywqemcvZ2WYfo3LHe+0RTp3vOkZqy 3XO2rWOPr33QMrPMLa3HMLFp09m5Vm+03wo2fS76wGUy+fK5R3tSJxTarLvU+qnzn/BGjset dzrFtZbsiBS8Y1b7aLe5zuH611MeCJ+0VDHSXqipL7Vx9++14meKm9dNvR9reT+ponCCEktx RqKhFnNRcSIAVucxLmYCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/S2LV6l9-FhYBq7fXN4SmomYrbbc
Cc: 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: Sat, 28 Jun 2014 00:50:43 -0000
Thank you for the response. I guess I am still not clear on the token-instance-grant binding. Let me look at the specs to see what the grant looks like to see if I understand. Any pointer is appreciated. R, Madjid From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Friday, June 27, 2014 11:22 AM To: Madjid Nakhjiri Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] refresh tokens and client instances Inline On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri <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: <mailto:oauth@ietf.org> 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/> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ John B. On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri < <mailto:m.nakhjiri@samsung.com> 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 <mailto:OAuth@ietf.org> OAuth@ietf.org <https://www.ietf.org/mailman/listinfo/oauth> 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