John, what you've described is more or less manual registration as it
stands today. But with Dynamic Registration and an open registration
endpoint, a smartphone client (for instance) actually *can* be a
confidential client now. It can store runtime secrets, and can therefore
protect a client_secret and a registration_access_token. It would just
be the case that each copy would register itself and therefore get its
own client_id (and client_secret) and not be directly tied to other
instances. This is the case that Phil is having trouble with, I believe.
Phil would like to see a mechanism for tying together all of these
copies of the client at each AS.
And I agree with John's statement below: in order to tie together
multiple instances, you *can* use the initial authorization to the
registration endpoint (which is in turn tied back to a developer), but
that requires much more specification in order to make it usable and
secure.
-- Justin
On 05/20/2013 10:51 PM, John Bradley wrote:
Dynamic registration provides:
1 A client_id
2 (Optionally) a client secret that is used at the token endpoint per OAuth. to
authenticate the associated client_id
3 a URI that can be used to update the client_id (this is a REST concept and
may be thought of as a instance of client_id rather than the generic
registration URI that takes a POST to create a client instance and assign it a
resource identifier (registration_client_uri) , Name (client_id) ,
client_secret and registration_access_token(access the new resource) . From
the API point of view this is a new new resource that is a instance of client
and NOT a new instance of a particular client.
4 a registration_access_token used by a developer or client to access the new
resource via registration_client_uri.
So we are being more REST like than OAuth and that may be confusing some
developers. Mike and I had concerns about that, but I think creating a
specific resource for each client_id is likely the correct thing in the long
term.
One slightly slipper part of this is that in some cases it may be the client
that is using this and in others it may be a developer.
Lets not forget one of the main current uses of OAuth in Phone apps. These
are not confidential clients even if they are using the code flow.
Typically a developer would use the dynamic registration API to create a client
at the AS. They would then take the client_id and bake that into there
distributed code. (this is super common now)
They would not get a client_secret and hold on to the registration_client_uri
and registration_access_token to be able to update settings for the deployed
client instances and to be able to revoke them possibly at some point in the
future. All client instances have the same client_id and client_secret (some
people like to use it even if it is not a real secret), the AS has no way to
differentiate between client instances. Perhaps that is a bad thing but that
is OAuth. We are not going to change the fundamental logic of OAuth in
registration.
One thing we did leave room for in the spec was building something on top of
Dynamic registration using a bearer token provided out of band to the developer.
That token might constrain or provide defaults for clients registered with it.
This however needs to be defined as a part of another spec. We discussed
possibilities for dynamically creating client_id and secrets for native apps so
that a code generated form phone A could not be intercepted by an attacker and
used to get a access/refresh token.
This is perhaps instance management from a high level but still conforming
OAuth from the perspective of the AS and the flows.
Looking at the wording we may not be doing a good enough job describing that out of access token
provisioned out of band for use at the dynamic client registration endpoint which is described as
"OAuth 2.0 [RFC6749] access token" in Sec 3 as opposed to registration_access_token which
is used in Sec 4.2, 4.3, and 4.4 to access the "Client Configuration Endpoint".
John B.
On 2013-05-20, at 12:36 PM, Phil Hunt <phil.h...@oracle.com> wrote:
Phil
On 2013-05-20, at 8:45, Justin Richer <jric...@mitre.org> wrote:
On 05/17/2013 07:29 PM, Phil Hunt wrote:
He's saying every client gets a registration token and a client token.
What's a "client token", exactly? There are three potential places for OAuth tokens in
and around dynamic registration, and none of them are called "client token".
<ph> i meant client credential. Client token is obviously a type of client cred.
1) The registration access token, which binds a "client" (or "instance of a
client", if you will) to a set of registration information at a specific authorization server.
The client uses this to call its Client Information Endpoint to do updates, refreshes, and
potentially delete itself. This token is *only* good at this Client Information Endpoint, and
nowhere else. This token is specific to the registration it represents.
<ph> This is not apparent at all. No more than binding the registration to the
client credential since the implication is one reg -> one client cred and one reg
token.
John Bradley has brought up seemingly other scenarios that would not bind but
rather associates a dev or an admin to a reg. i may be wrong. I have not had
time to consider his explanations yet.
What seems clear is that there is confusion as to the purpose and role for this
token and what the use cases are for registration.
My plan is to review and suggest clarifying text and changes if necessary this
week.
2) The (optional) initial token used to authenticate to the Client Registration
Endpoint. This is *not* the registration access token, and it is *not* used to
access the Client Information Endpoint. How the client or developer get this
token is out of scope. How the registration server validates this token is out
of scope. The structure and contents of this token are out of scope.
3) The access/refresh tokens that a registered client eventually gets from the
Token Endpoint and uses with protected resources. These tokens aren't used at
the Client Registration Endpoint or at the Client Information Endpoint.
There are also a couple of related concepts that aren't tokens at all:
4) The client_id, which is issued to a "client" (or "client instance") by the
authorization server. This must be unique at the auth server for each client instance. The client
uses this client_id at the Authorization Endpoint and the Token Endpoint in normal OAuth flows.
5) The client_secret, which is issued to a "client" (or "client instance") by
the auth server, for confidential clients (ie: clients that can protect their client_secret). This
is used by the client to authenticate to the Token Endpoint and nowhere else.
Which of these do you mean by a "client token"?
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
