Direct User Authentication for a Standalone REST API

Our firm has a web application with users authenticating via Auth0. We are now developing a REST API and we want to allow certain users to access it directly without having to authenticate in a web browser. I’ve been scouring the documentation and the only solution that seems to present itself is to use the “Resource Owner Password Flow”. My first red flag is the giant warning block at the top of those docs but I think our own 1st party application can be trusted. When I tried to implement a POC using this auth flow, I came across this doc which seems to indicate that I also need an Auth0 application client in addition to the API. My thoughts in this case would be that I would create an “application” that is the REST API client and then intercept the credentials passed via the REST request and hydrate them with the client ID and secret before forwarding to Auth0 to generate a token.

Am I approaching this problem from the correct direction? Is there something obvious I am overlooking?

Hi @richard6,

Welcome to the Auth0 Community!

If you need to exchange credentials directly for a token, the resource owner password flow is the way to do that.

Yes, you will need a client that is registered and has that grant turned on.

What I’m missing, is how the credentials are being sent initially? How does the username/password get to your client?

Nothing is yet live in production but the thought was to use a POST request with a content type of “application/x-www-form-urlencoded” which is how I see the example in your API docs. Does this track with what would be secure and good practice? So a user would make a request to my API’s token endpoint with their credentials and then I would use that to build a request using the Auth0 .NET package.

Okay, I think that’s what we’ve been missing.

Typically, you would be issuing these third party developers each their own client ID and secret, and they would make their requests with client credentials.

Think about it this way; each of these users are essentially creating their own client (AKA application) that is going to interface directly with your API. Because of this, the users should each have their own app registered with Auth0, and should use those credentials to make requests against your API. This is the OAuth2 way of doing things- you see it with most major SaaS providers like Slack, Google, etc.

Hope that helps!

Thank you for the clarification. So creating a new client per API user would be the recommended approach even for individual users? I guess I misunderstood the documentation on the resource owner flow. Could you provide a concrete example of a use case for this type of password grant?

An example of the resource owner password grant would be if you had an embedded login page in your application that sent credentials directly to the auth server. There’s an example flow in the doc here: Resource Owner Password Flow

edit: We don’t recommend using this grant type. It’s typically encouraged to avoid it due to the security implications. If you have questions about the implications, you’ll find many articles about it on the web.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.