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 ?
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 ?
Thanks, Sergey
John B.
On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin <sberyoz...@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
<sberyoz...@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.nakhj...@samsung.com
<mailto:m.nakhj...@samsung.com>
<mailto:m.nakhj...@samsung.com <mailto:m.nakhj...@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:ve7...@ve7jtb.com
<mailto:ve7...@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.nakhj...@samsung.com
<mailto:m.nakhj...@samsung.com>
<mailto:m.nakhj...@samsung.com <mailto:m.nakhj...@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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
