[OAUTH-WG] Rotating client secret

[Amarendra Godbole <[e-mail]>]

Hi All,

First post to the list, and hopefully I am articulate enough to describe the problem I am facing — did OAuth ever consider an ability to dynamically rotate client secret (part of the “client credentials” authorization grant)? I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration Protocol), but the OAuth 2.0 implementation I am looking at [1], does not support it. I also found some previous reference to client secret rotation [2], but it does not discuss my use case.

We operate a SaaS application A, which is supposed to talk with another SaaS application B. Our customers subscribe to both, our application A as well as application B. However, the teams adminstering A and B are separate teams within the same organization, though we cannot assume the level of trust between them. Let’s call them Tenant Admin A and Tenant Admin B. In our usecase, application A is the client for application B, and application B provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to provision the "client credentials” authorization grant — in order to do that, Tenant Admin B generates the client_id and client_secret, and sends them to Tenant Admin B. There is the problem — as I earlier stated, we cannot assume the level of trust between Tenant Admin A and Tenant Admin B, and exchanging client_id and client_secret now means the circle of trust for application B includes individuals who may or may not be trusted.

One thought that occured to me was a provision in OAuth 2.0’s client credentials grant flow was the ability to “bootstrap” a client application — basically the client_secret is one-time-use-and-timebound-only, and allows the client to exchange it for a different client_secret. In our case, this can be handled by the SaaS application backend, thus making sure the Tenant Admin A no longer have access to it once they provision the client. This can be generalized, such that the authZ server can periodically trigger client_secret rotation, and won’t require manual intervention [3]. As I stated earlier, rfc7591 talks about this, but but in the context of dynamic registration.

Having the client secret rotation a part of the protocol exchange messages, maybe a bootstrap, would be the ideal solution for our usecase.

Or the bigger question: Did I misinterpret it all? Looking for guidance from this list.

Thanks in advance.

-Amarendra

[1] Microsoft Azure https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-app-types <https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-app-types>
[2] https://mailarchive.ietf.org/arch/msg/oauth/7ICMSRI2tjfXDD1Bk_G-qNpLy-0/ <https://mailarchive.ietf.org/arch/msg/oauth/7ICMSRI2tjfXDD1Bk_G-qNpLy-0/>
[3] Auth0 rotate client secret: https://auth0.com/docs/dashboard/guides/applications/rotate-client-secret <https://auth0.com/docs/dashboard/guides/applications/rotate-client-secret>