I'm not sure if it is just me, but I'm not sure I'm totally following. I can see a concrete analogy being that, Tenant application B could be Google Drive, and Tenant application A being any front end app that wants to offer a service that saves files in a user's Google Drive. If application A wants to interact with application B offline then tenant A needs a service client/secret along with an authorization grant initiated through application A (currently via UI in OAuth2).
Whether application A cycles the client secret or not seems like a different problem. But I think I'm missing something. Given the example I provided, would you be able to provide more insight into the problem you are seeing? *Warren Parad* Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>. <https://rhosys.ch> On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole <ag= 40broadcom....@dmarc.ietf.org> wrote: > 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 > [2] > 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 > > _______________________________________________ > 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
