Re: [OAUTH-WG] refresh tokens and client instances

Madjid Nakhjiri <m.nakhjiri@samsung.com> Fri, 27 June 2014 17:24 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 E3AE51A037D for <oauth@ietfa.amsl.com>; Fri, 27 Jun 2014 10:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.651
X-Spam-Level:
X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 sefApOJImyMS for <oauth@ietfa.amsl.com>; Fri, 27 Jun 2014 10:24:16 -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 602481B28DB for <oauth@ietf.org>; Fri, 27 Jun 2014 10:24:15 -0700 (PDT)
Received: from uscpsbgm2.samsung.com (u115.gpu85.samsung.co.kr [203.254.195.115]) 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 <0N7U00CGI8CEOZ80@mailout1.w2.samsung.com> for oauth@ietf.org; Fri, 27 Jun 2014 13:24:14 -0400 (EDT)
X-AuditID: cbfec373-b7fd56d0000060dc-6b-53ada8be14c8
Received: from ussync4.samsung.com ( [203.254.195.84]) by uscpsbgm2.samsung.com (USCPMTA) with SMTP id 77.5B.24796.EB8ADA35; Fri, 27 Jun 2014 13:24:14 -0400 (EDT)
Received: from sdsamadjidPC ([105.66.230.137]) by ussync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0N7U008LR8CDJL10@ussync4.samsung.com>; Fri, 27 Jun 2014 13:24:14 -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>
In-reply-to: <0BA8278C-6856-4C9F-96C7-C5752F3F1E09@ve7jtb.com>
Date: Fri, 27 Jun 2014 10:24:14 -0700
Message-id: <002201cf922c$9ec65c90$dc5315b0$%nakhjiri@samsung.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_0023_01CF91F1.F2678490"
X-Mailer: Microsoft Office Outlook 12.0
Thread-index: Ac+Q2UIzBLNZgFI1Qt+pSRGhpSl84wBUG7Rw
Content-language: en-us
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/hEN19K9YGG/S+FbM4+fYVm8Xqu3/Z HJg8liz5yeRx+/ZGlgCmKC6blNSczLLUIn27BK6Ma0e2MxWsrau4sqWRrYFxRl4XIyeHhICJ ROvSmawQtpjEhXvr2boYuTiEBJYwSnSevc4I4bQwSTT+uMcCUsUmoCexf94MZhBbREBNYvn2 TnYQm1lASOLDpSawGiGBMolFP5+B1XAK2Emc2HSbCcQWFrCWeLPuOFicRUBVYt2RM2C9vAJO EoteNLBC2IISPyZD7GIWiJa4/mUZ0BEcQNepSzz6qwux1kji6u45zBAl4hKTHjxkn8AoOAtJ 9ywk3bOQlM0CmsQM9EHbRqiwvMT2t3OYIWxdif/PYWxtiWULXzMvYGRfxShaWpxcUJyUnmuk V5yYW1yal66XnJ+7iRESDcU7GF9ssDrEKMDBqMTDK7B4bbAQa2JZcWXuIUYJDmYlEd5H84FC vCmJlVWpRfnxRaU5qcWHGJk4OKUaGN25SvNDLbI+GHSxdHJPSlDWb2Up2XXebvUz812CbJIc G/i63mu2R9sfzXtaePSUasSdxBaDi7enn00z5l22g/0H10M5o1CNyJ0NnK+mhr0UKJq2k+HM NxZ3VWPVooMzXKVFmewepBo/8RW/mSMU2/nqYtX967unxLbL8wVnO1hs8Dzbu8tViaU4I9FQ i7moOBEA2qZR+2QCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zZ5T-U6H1SKTAJVx3GBEX1hpPug
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: Fri, 27 Jun 2014 17:24:21 -0000

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] 
Sent: Wednesday, June 25, 2014 5:56 PM
To: Madjid Nakhjiri
Cc: 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 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?

 

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)?

 

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?

 

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> 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