+1 ________________________________ From: John Bradley Sent: 2/12/2013 8:20 AM To: Justin Richer Cc: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Registration: Client secret rotation
Yes, that agrees with my thoughts on it. John B. On 2013-02-12, at 11:29 AM, Justin Richer <jric...@mitre.org> wrote: > 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
