I just recently set up a Resource Owner Password flow in Auth0, and I managed to get it working for a short period since I’ve been able to retrieve Access Tokens successfully from the /oauth/token endpoint. Unfortunately something has happened to Auth0 within the past 24 hours that has caused this setup to fail. Now every time I try to retrieve an access token I get a 401 response with the following error:
Grant type ‘password’ not allowed for the client.
I’ve tried a number of things to rectify the situation:
Ensured my Auth0 Client and API are set up correctly. I’ve done this by comparing my Client and API to ones that I know work properly. It didn’t work.
Recreated my Client and API and set it up correctly. It didn’t work.
Recreated my Client and API with a brand new Connection, set up my users, set my default connection. It didn’t work.
Created a brand new Auth0 account set up my Client and API correctly, added my users, set up my default connection. It worked!
Is there something wrong with our https://yellowlineparking.eu.auth0.com account? The /oauth/token endpoint appears to work just fine when I create a new Auth0 account, so this seems to be the case.
Here’s the request I’m sending off to the /oauth/token endpoint, sans the client_secret, username and password.
We are in the process of rolling out changes aimed at improving the default configuration that gets assigned for new clients that are created. This is in progress right now so you may not see the same behavior in totally independent accounts; this is the likely explanation for why you saw the different behavior when you created a new account.
As a measure to not break existing client applications and as mentioned before, these changes only affect new client applications.
In relation to the root cause of the actual error the explanation is that by default the resource owner password grant is not included in the allowed grant types for new client applications. Given this grant implies the capability for an application to directly exchange user credentials for tokens we did not include it by default as this should be a conscious decision from the part of the developer and should only be enabled for highly trusted clients…
You can use the Management API to patch a client that you recently created to include these additional grant types, in particular, for the resource owner password grant you would be interested in adding the following grants:
password
http://auth0.com/oauth/grant-type/password-realm
For your convenience a sample body request for the PATCH client call:
{
"grant_types":
/* add your other required grants here or the grants that the client already has */,
"password",
"http://auth0.com/oauth/grant-type/password-realm"
]
}
UPDATE:
See additional information about these changes at:
Thanks for that! I’ve gone to the Management Client as suggested, set my API Token, entered my client_id and the JSON body you’ve suggested (minus the comments), and it’s added those grant_types against my new client app. Grant_type=password requests are working on /oauth/token now!
on day N i create a client, then on day N+1 i create another client and it behaves differently. Is there any notification channel for when these sorts of changes are rolled out?? this cost us a bunch of time today trying to sort out.
The above solution (manually adding grants) worked for us. Everything just worked before…and then our 2nd auth0 installation was updated but not our 1st, leading to this weird problem.
The above solution (manually adding grants) worked for us. Everything just worked before…and then our 2nd auth0 installation was updated but not our 1st, leading to this weird problem.
The password grant represents the OAuth2 resource owner password grant; since by the spec this grant does not specify any parameter to indicate to which realm/directory/connection the user should be authenticated against we also have a corresponding password realm grant that allows an extra provider specific parameter. When you use the password grant the user is authenticated against the default connection you configured in your account settings.
By default new clients that get created as native or non-interactive do not receive the password or password realm grants. However, if they are first-party client application that you trust to directly handle user credentials you can still patch them through the Management API to include those grants and they will then be able to perform them. For your second question given there are many things that can cause a refresh token to not be issued I would suggest you to create a separate question if you haven’t done so already.
By default, the legacy grant types can only be enabled by existing customers/accounts at the day the change occurred (see the linked docs in the main page for additional information). In addition the grants that require direct handling of user credentials like the password or the .../ro grants are only available for trusted first party applications.
I do understand your concerns, however, developers using us do it because they want to offload a big part of their security requirements. This means it’s our responsibility to always be pushing for increased security by default; given security is a moving target this implies that sometimes changes need to be introduced and enforced. We aim at trying to introduce those changes with the minimal disruptions as possible but it’s change nevertheless.
A notification would be great, I am pretty sure I used to see notifications of this nature from the dashboard… its seems there are a few good things that have gone missing in recent times…
follow this to create the token
then head back to the "Patch" client api interface
and paste in the grant types settings and apply that, you should then see all the client setting in the result with the updated grant types.
Hi there, did you apply the legacy grants? I’ve updated my client to with is_first_party : true but still no luck. I’m get 401 for my authenticated endpoints.
This really is a nightmare. I downloaded the Embedded Login sample. It should come with the variables already filled. It didn’t but that was not much of a problem. The problem was it didn’t work – giving the “grant type…” error in the console. First it doesn’t look like “Patch Client” is in the API anymore as the link takes me to “Update Client”. So I have set the API token and am looking at the “Update Client” API. I mouse over the “update:clients” button and it says “Your token does not permit this scope”. All this because I just wanted to try out the example!!
This really is a nightmare. I downloaded the Embedded Login sample. It should come with the variables already filled. It didn’t but that was not much of a problem. The problem was it didn’t work – giving the “grant type…” error in the console. First it doesn’t look like “Patch Client” is in the API anymore as the link takes me to “Update Client”. So I have set the API token and am looking at the “Update Client” API. I mouse over the “update:clients” button and it says “Your token does not permit this scope”. All this because I just wanted to try out the example!!