Best OAuth flow for long-term user data sharing with third-party after one-time consent

Get Help
,
1

Hello everyone,

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:

    1. API where the third party can fetch complete user information.

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

Option 2: Authorization Code Flow (Consent) + Client Credentials Flow (Data/Webhooks)

  • Pros:

    • Third party only manages one token.

    • Works for both user data API and webhook lifecycle API.

    • Lower load on Auth0.

  • Cons:

    • Less “pure” OAuth flow (hybrid approach may confuse partners).

    • Requires exchanging userId in consent flow.

    • Flow begins with user-based consent but continues as server-to-server.

My Questions

  • Is there a more appropriate flow or pattern for long-term, post-consent data sharing that still respects OAuth principles?

  • If not, which option above aligns better with industry best practices for this type of integration?

  • Any guidance on making the third party integration simpler without sacrificing security?

Thank you for your insights!

3

Hi @Coust

Welcome to the Auth0 Community!

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 a userID, 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.

Have a great one!
Gerald