Ah! That isn’t the issue as much as the fact that Admin B does not want to share the client_secret with Admin A in the first place!
As Dick Hardt suggested earlier, we are already considering moving it up a layer since this is largely a trust-between-humans-issue, though its still a bummer that OAuth2 doesn’t support rotating client_secret. Thanks everyone who responded, I have enough food for thought! -Amarendra -- sent via recycled electrons, from my portable command center. > On Jul 13, 2020, at 3:50 PM, Warren Parad <[email protected]> wrote: > > Why is #3 a problem, and why do the admin A incorrectly use App A to store > the service credentials of App B in their repository? Admin A should be using > their source control/database to store the tenant B client secret. > > 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 11:34 PM Amarendra Godbole <[email protected] > <mailto:[email protected]>> wrote: > Let me see if I can provide more details on the usecase: > 1. A tenant is subscribed to SaaS application A and SaaS application B, and > both applications are separately managed by different teams in the same > organization. No assumption can be made about the trust between those teams. > 2. Application A backend is supposed to access Application B. App B also has > the authorization server. Both applications expose administration UI for its > tenants. > 3. App B admin generates client_id and client_secret, and hands them over to > App A admin. > 4. App A admin enters the client_id and clilent_secret in the UI, so the > backend App A can now communicate with/access App B. > > #3 exposes client credentials of App B to admins of app A — this is our > problem. As stated in #1, we cannot make any assumptions about the level of > trust between the two groups. > > If OAuth2 provided a client credential rotation, this exposure of credentials > can be limited to a small time window. The original client_secret can be a > one-time-use-bootstrap, that App A backend exchanges for another secret from > the authorization server. Generalizing it, the OAuth2 spec can provide for > servers to trigger a client_secret rotation. > > To your analogy, the front-end app can “leak” the credentials during > provisioning (it can be a simple copy/paste that the user has to do), thus > creating a security issue. But if the credentials are one-time-bootstrap, > then first time the front-end app connects to Google drive, drive changes the > client_secret for a different one, which then would be used by front-end app > in the future. Drive also has the ability to periodically rotate the > client_secret in a similar manner. This assumes front-end app cannot access > the client_secret once it is provisioned. > > Is this better? Thanks! > > -Amarendra > > -- > sent via recycled electrons, from my portable command center. > > > >> On Jul 13, 2020, at 1:48 PM, Warren Parad <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 >> <[email protected] <mailto:[email protected]>> >> 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 >> <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> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
