I’m currently refactoring a system and need advice on the most appropriate OAuth flow for my use case. I’ve reviewed the standard flows, but none seem to perfectly fit my needs. Here’s the context:
My platform generates user information that updates very frequently (several times per minute).
I need to share this information with an external third party, but only after explicit user consent.
The consent request is initiated from the third party’s website. Once granted, I can start sharing the data.
There are current two delivery methods:
API where the third party can fetch complete user information.
Webhook notifications (sent as lightweight alerts). The third party must call the API to get the complete data after receiving a webhook.
Additionally, I have an API to manage webhook subscriptions/lifecycle that also requires authorization via OAuth.
On the surface, getting user consent and allowing data retrieval fits the Authorization Code Flow pattern:
The user logs in and accepts the contract.
Consent remains until revoked.
However, data sharing continues for a long time after consent (while the user is inactive or offline). Especially with webhooks, this starts feeling more like a server-to-server (B2B) integration than an ongoing “active user session” scenario, even though the data belongs to the user.
At this point I’m considering multiple options:
Option 1: Authorization Code Flow + user access/refresh token for each user
Pros:
Standard Authorization Code flow.
Third party doesn’t need to know my internal userId.
Cons:
Third party must store two tokens per user (access + refresh).
More complex for integration.
Higher Auth0 token refresh load.
Doesn’t solve webhook API authorization (I’d still need Client Credentials flow separately).
Firstly I must applaud your initiative and the intricate work flow that you are looking to implement!
Reading through all the information, allow me to try and provide some clarity for your questions:
At this moment there isn’t any one flow that would satisfy the entire process that you are looking to implement and a hybrid flow will be required in this case regardless;
I strongly believe that your second option of combining Authorization Code Flow with Client Credentials Flow makes the most sense and would be the most practical approach. While tackling the user consent part would naturally be handled through the Authorization Code Flow, the frequent updates to the user information and communication with the third party provider makes the most sense to be handled through Client Credentials Flow.
In terms of security, you are taking advantage of two official OAuth flows that are built around security principles and should not be an immediate concern. You should look into using standard claims to lighten the load ( instead of custom claims that might bring difficulties in adapting both flows ) and ensuring a robust way of linking the client’s access token to the user’s consent, which will be achieved by exchanging the userID.
In an attempt to address your concern about exposing the userID to the third party, as a workaround ( although this might prove more of a hassle for working with a large number of users) I recommend reading through our article on how to Change a Database User’s user_id without Reimporting the Password Hash. Although not ideal, it can provide a solution of exposing auserID, but not the original one, if you might see this fitting for your use case.
I do believe that it can be a good idea to look into our subscription option on the Pricing page in order to:
facilitate and handle higher rate limits, that could play a role in this setup;
have access to our higher level Support tier to provide more specialized assistance with this complex integration.
Allow me to add the following documentations just to have them handy:
I hope I was able to provide some clarity on the overall course of your integration! Please do not hesitate to reach out to us for any other issues or requests.
This is a pretty common pattern, honestly. Once consent is given, the interaction really does shift into a long-lived server-to-server relationship.
Most teams I’ve seen go with something like your Option 2: use Authorization Code purely for consent, then switch to Client Credentials for ongoing access and webhooks. It keeps things simpler operationally and avoids juggling per-user refresh tokens forever. As long as scopes, consent records, and revocation are handled cleanly, it still fits OAuth’s intent and is easy for partners to reason about.
Hello gerald.czifra and thank you for your answer, it brought a lot of clarity to my doubts. I’m definitely going to take a look at our tier to see if we can get the extra support for this.
I have a next question: in case we use the Client Credentials flow, we need to expose a userId during the consent flow (or a representation of our internal userId, but for simplicity let’s assume we want to expose the userId directly). Is there any recommended way of doing this?
I have been doing some research, and it seems one possible way is to return the OpenID Connect id token in the /oauth/token response and ask the third party to extract the specific claim containing the userId information. However, it feels a bit weird (or hacky) to ask the third party to complete the authorization code flow for consent, obtain both the access token and the id token, extract only the userId claim from the id token, and then discard the tokens to start over with a client credentials flow to fetch the data.
Is there any other way of providing the userId to the third party without generating confusion?