OAuth flow for allowing third party applications to access API

Help
,
1

Hello,
We want to allow an external customer application to access our APIs.
Below is the scenario:

  • End users login to external customer web application.
  • The web application should be able to make calls to our APIs directly from the web browser.
  • We don’t want to create those end users in our Auth0 tenant.
    Could you let me know which Oauth 2.0 flow would be applicable for this scenario?
3

If you only had listed the first two points then the recommendation would be for you to create a thrid-party application in your tenant to represent your customer application (First-Party and Third-Party Applications). The application could then use any of the OAuth 2.0 flows to obtain an access token that would allow it to call your API.

However, the above implies that the end-users authenticating into that third-party application will need to exist in your tenant.

Can you clarify how literal is the third point you mentioned; in particular, when you say:

don’t want to create…

does this mean that you just not want to have to create these users because you don’t really manage their credentials and as such this is a dynamic set of users that is controlled by your customer?

If yes, then this would be solved by your customer providing their own identity provider for this set of users and you would just create a connection in your Auth0 tenant; this way any user from the upstream identity provider (your customer) could login without you having to first create any user profile record in Auth0.

However, the above would still lead to user profiles being created in your Auth0 tenant; so if your third point is about not having any notion of those end-users in your own Auth0 tenant then I don’t see how this could be made to work.

4

Thanks jmangelo for the response. Yes, the customer is managing the users and their credentials and we don’t have control over it.

I am thinking if the below approach would work:

  • We’ll share a client_id and client_secret to the customer.
  • Once the user logs into the customer application, the customer application server side code will hit the auth0 token endpoint passing the client credentials, custom claims like user name, roles and scopes to generate a token.
  • The customer server side code will store this generated token for the user in their backend and pass it to the browser code when required.
  • The browser can make calls to our APIs using this token.
  • On our API side, we’ll validate the token and decode it to get the user name, role and scopes.

Do you have any comments on the above approach?

5

Although technically feasible you would be using a hacked client credentials flow to actually obtain a token that contains user information. I would personally avoid this simply because it’s really unexpected and you would be using a flow for something that the flow as not designed.

Although the customer manages the users, if that customer has any identity provider supporting OIDC/OAuth 2.0, WS-Federation or SAML you could quickly integrate those users by having just one connection in your tenant. Why is that not feasible?

6

Hello jmangelo,

what will the flow in case of passwordless connection being offered to the customer?
how authentication works for external apps in case of passwordless connection.

Thanks