Using the Request Owner Password Endpoint on a new dev account

[aitzol.casado]

Hi I wanted to use Auth0 to test a native desktop Java Swing app designed to uses the “Request Owner Password” flow. The Auth0 implementation seems to be the “/oauth/ro” endpoint.

Unfortunately, according to the API doc’s “This feature is disabled by default for new tenants as of 8 June 2017.”
https://auth0.com/docs/api/authentication#authenticate-user

Is it possible to “enable” this endpoint in order to be able to test the workflow?

Thanks,

Kind regards,
Aitzol

[Carlos_Mostek]

It should not be necessary to use the /oauth/ro endpoint.

There are two alternatives.

1. we highly recommend not using the Resource Owner Password Grant flow for Native applications. It goes against the IETF standard for a variety of reasons. I highly recommend you read through the concerns before implementing this flow (including following the links below and reading the concerns laid out in the standard).

In the RFC 8252 OAuth 2.0 for Native Apps from the Internet Engineering Task Force (IETF) it is recommended that “OAuth 2.0 authorization request from native apps should ONLY be made through external user-agents, primarily the user’s browser”. It clearly lays this out here. There is also more information on this in OAuth 2.0 Best Practices for Native Apps.

2. If you truly must use ROPG in your native app instead of PKCE as is recommended, then you can use our OIDC compliant ROPG endpoint. Instead of /oauth/ro.
3. If there is some reason you can’t use that endpoint, then you can create a support ticket to get /oauth/ro enabled on your tenant, but you will have to justify why the above two options won’t work for you in the support ticket.

[aitzol.casado]

Thanks @Carlos_Mostek,

Unfortunate we are talking about a legacy application. Whilst adding login via a browser (probably by bundling in a webkit browser) is planned, this is will not happen for a while and is out of my control. In the mean-time we need to add 0Auth2/OpenIDC so ROPG seems like the way to go right now.

I’ve tried using the endpoint you indicated, but I am getting the following 500 Internal Server Error response:

{
    "error": "server_error",
    "error_description": "Authorization server not configured with default connection."
}

POST https://{URL}.eu.auth0.com/oauth/token
{
    "client_id": "***",
    "connection": "email",
    "grant_type": "password",
    "username": "***",
    "password": "***",
    "scope": "openid"
}

Reading around the forum, it looks like I need to set the Default Directory in (my) the test user’s account settings. Could you clarify what I need to set this value too?

How to authorize user with email/password from server code?

Thank you, @jmangelo, that got me over the hump. With a little more struggling with poor docs and error messages I have managed to get registration and login working. I hope that password reset will be simple!

Thanks.

kind regards,
Aitzol

[Carlos_Mostek]

You have two options:

1. Use the password-realm grant type. Just pass the different grant_type and then you can add an additional “realm” property to the call which should be set to the database connection name you want to use
2. Go to your tenant settings (drop-down in the upper right side of the manage dashboard). I believe it is on the general page, you can set the default connection for ROPG there.

[aitzol.casado]

Thanks @Carlos_Mostek,

So finally got the /token endpoint working. I indicate below the exact config in case anyone else has the same issue in the future:

URL endpoint: https://{AUTH0_DOMAIN}/oauth/token

Post body:

{
    "client_id": "***",
    "grant_type": "password",
    "username": "email@provider.com",
    "password": "***"
}

Client Application settings:
The Client application who’s client ID you are using must be of type native and password must be checked within the Applications -> Settings -> Advanced Settings -> Grant Types pannel

Tenant Settings:
(Under tenant user account → settings)
Set General -> API Authorization Settings ->Default Directory to Username-Password-Authentication

Hope this helps someone.

Kind regards
Aitzol

[alexandra.damaschin]

I tried your solution because I have the same problem, but when I try to set Client Application settings and Tenant Settings both are forbidden so I am not able to set them.

Did somebody else had this problem?

[basickarl]

You maybe do not have permissions to see that part. You have to be admin if I am correct.

@aitzol.casado Thank you! It works fine, your example.

@Carlos_Mostek Currently we are trying to run contract testing internally in our CI pipeline and I’m wondering if there is a “proper” way to do this. What we need is a user access token which will then be used in requests towards our API which we are testing. Currently the solution above with Aitzol is working. We make this request from our CI runner agent to Auth0 with the users credentials and receive the access token, we then use this access token in said requests. I’ve tried reading the Auth0 documentation but it’s unfortunately quite a mess. Is there anything you could suggest in how we should change our approach or is it good enough?

[jacques.thomas]

I just hit “Authorization server not configured with default connection.” again on a new tenant and decided to post the solution here.

For your tenant, under Settings->General, go to “API Authorization Settings” and setup the “Default Directory” (see the screenshot, where it’s offering to use the built in DB from Auth0).

[konrad.sopala]

Thanks for sharing that with the rest of community!

[Carlos_Mostek]

Sorry it took so long to reply, just found this in some archived emails I was going through :).

For testing in a CI pipeline using the above password grant for getting a user based access token is a great way to do this as part of a test pipeline. It is one of the few cases where the password grant is a good thing! Here are the docs for it: Authentication API Explorer

As @jacques.thomas pointed out, you have to either set the default connection, or use the “realm” parameter to specify which connection to use.

I would recommend, as a best practice, that you create a separate application and separate database so that you don’t risk the password grant or test user getting exposed to your general user population, maybe also disable signups. Generally, you want password grant disabled on all of your applications. This way you don’t risk someone accidentally enabling it on a client where the token authentication is set to None.

[konrad.sopala]

Thanks for following up on that Carlos!