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
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 architec
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 Amarend
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
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 wan
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 Registrat
