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 <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of > Justin Richer > Sent: Monday, February 11, 2013 1:15 PM > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
