Subject: [OAUTH-WG] Rotating client secret

From: Amarendra Godbole <[email-masked]>
Date: Mon, 13 Jul 2020 13:28:36 -0700

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>

---

From: Warren Parad <[email-masked]>
Date: Mon, 13 Jul 2020 22:48:12 +0200

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=
[email-masked]> 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.
>
> [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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Amarendra Godbole <[email-masked]>
Date: Mon, 13 Jul 2020 14:34:16 -0700

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-masked]> wrote:
> 
> 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=[email-masked] <mailto:[email-masked]>> wrote:
> Hi All,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 14:41:46 -0700

I don't know of any discussion for client secret rotation.

Another way to solve your problem could be to raise it up a layer. Admin B
generates a one time use URL that is sent to Admin A. Admin A visits the
URI and obtains the client_id and client_secret.

On Mon, Jul 13, 2020 at 2:35 PM Amarendra Godbole <ag=
[email-masked]> wrote:

> 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.
> 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
>
> --

---

From: Warren Parad <[email-masked]>
Date: Tue, 14 Jul 2020 00:50:21 +0200

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*

---

From: Amarendra Godbole <[email-masked]>
Date: Mon, 13 Jul 2020 17:39:56 -0700

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

> On Jul 13, 2020, at 3:50 PM, Warren Parad <[email-masked]> 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
> On Mon, Jul 13, 2020 at 11:34 PM Amarendra Godbole <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 13, 2020, at 1:48 PM, Warren Parad <[email-masked] <mailto:[email-masked]>> wrote:
>>