This is actually the approach that I favor now as well -- let the server
do the secret rotation if it wants to, and have the client be prepared
to receive a new client_secret or registration_access_token on any read
or update request.
This would necessitate changing the returned values, essentially
collapsing the returns from the read/update and rotate actions into one
structure that's closer to the one returned from initial registration.
This has the added benefit of parallelizing the responses for these
three actions, which I like as well.
-- Justin
On 02/11/2013 08:42 PM, John Bradley wrote:
OAuth doesn't say anything about client secrets other than they are provisioned
in a magic realm outside the OAuth spec (Getting in the mood for the next IETF).
Rotating client secrets was something I made up for connect because it seemed
like a good idea at the time given that someone breaking in to the registration
endpoint could take over a connection.
We later separated the authentication to the token endpoint from the
registration endpoint,in what I think was a good move.
It is sort of up to the authorization server to make decisions about rotating
client secrets, I expect that in the real world a client would try access ing
the token endpoint and get back a invalid_client error response and then heck
it's registration to see if the client_secret has changed.
I suppose that a client could request rotating its secret if it thinks it has
been compromised, however the compromiser is more likely to quickly change the
secret to lock out the legitimate clients before the good one notices. I
think the client wanting to rotate is enough of a edge case that it could deal
with it out of band.
Letting the server rotate the client secret according to what ever policy it
decides is best is probably safest.
We didn't have anything for rotating the access token. I suspect that rotating
it under the clients control is going to create as many problems as it solves.
If you want to rotate it, make it a refresh token that is issues and use OAuth
to provide access tokens from the token endpoint. Creating a new endpoint to
duplicate existing OAuth functionality is overkill.
John B.
On 2013-02-11, at 10:18 PM, Mike Jones <michael.jo...@microsoft.com> wrote:
The rotate_secret operation was added to OpenID Connect Registration as a
workaround to the fact that registration updates used to be authenticated using
the client secret, so it seemed overly dangerous to have an update operation
potentially return an updated secret and have the secret be lost due to
communication problems - leaving the client stranded. Since then, registration
was changed to use a bearer token to authenticate update operations, and so
this failure mode can't occur anymore. It was an omission not to have deleted
the unneeded operation then.
It's been deleted from OpenID Connect Registration and should likewise be
deleted from OAuth registration, since it is unneeded. If a new client secret
is needed, there's nothing stopping the registration server from returning it
in the result of an update operation.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Client secret rotation
Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the
client requesting a new client_secret (if applicable) and a new
registration_access_token. Client secrets MAY expire after some period of time,
and this method allows for a refresh of that secret. Draft -00 defined no such
operation, drafts -01 through -04 defined this operation in terms of the
operation=rotate_secret parameter, and draft -05 defines it through a secondary
endpoint, the Client Secret Rotation Endpoint.
This raises several questions:
- Should the client be allowed to request rotation of its secret?
- Would a client ever take this action of its own accord?
- Can a server rotate the secret of the client without the client asking? (This seems
to be an obvious "yes")
Alternatives that keep this functionality include defining the rotate_secret
operation in terms of an HTTP verb, a query parameter, or separate endpoint.
Alternatively, we could drop the rotate_secret operation all together. If we do
this, we have to decide if the client secret can still expire. If it can, then
we need a way for the client to get this new secret through a means that
doesn't require it to request a change in secret, such as sending it back as
part of the client READ operation (see other thread on RESTful verbs).
-- Justin
[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
