Simply getting a JWT in exchange for a user/pass

[Civility]

We wanted to test our web app using Cypress, and the discussion around the existing tutorial kept bringing up numerous issues.

Seemed that a far simpler way to test with Cypress would be to create a user/pass test user, login that user programmatically, and save the JWT. Found this thread, not promising (see the last 2 comments, which we unfortunately agree with).

How to obtain user JWT token from username/password?

I am an Auth0 noob, and am able to create a new user with the Management API after I get a token for the using the Management API for my specific Auth0 application. My question is, how do I procure a authentication JWT for a specific user using username and password, but with using API, not a browser based method like Lock. Please provide examples with links to the correct URLs within Auth0. I have been looking for this for a while now with no success. If I may provide general advice on your tut…

Another thread received no reply:

Programmatically get a test user's jwt for CI/CD backend tests

I use jest for my automated tests and currently have a nice test harness for sending post requests to my server. I hard code a string with the current test user’s jwt and all the tests work perfectly but if I wait 24 hours, the jwt expires and my end to end tests fail. Is there a way my test environment can get a current jwt that matches what a test user would get from the website? I can get auth0 tokens but they don’t have the same ‘email’ ‘app_metadata’ and other things like that which I’d ex…

Going back to first principles, it turned out obtaining a JTW was also far simpler than suggested in those threads, so I’m posting this here for anyone interested. CC-ing folks from the closed topics, since it’s impossible to reply there and notify those who were interested: @stephen, @sonny.rajagopalan, @amanda.harmse.

---

What we all want in these threads is called “Implement the Resource Owner Password Grant”, and the Node.js code is provided in the Ask for a token section. Here’s a modern adaptation of it:

import fetch from 'node-fetch';
import { URLSearchParams } from 'url';

const params = new URLSearchParams();
params.append('grant_type', 'password');
params.append('username', 'user@domain.com');
params.append('password','supersecretpassword');
params.append('scope', 'read:sample');
params.append('client_id', 'the client id of the application you created, in our case a Cypress machine-to-machine application');
params.append('client_secret', 'the client secret for the application above');
params.append('audience', 'the identifier API that this application is linked to; we used our GraphQL API');

(async function main() {
  const response = await fetch('https://YOUR-DOMAIN/oauth/token', {
    method: 'POST',
    body: params,
  });
  const json = await response.json();
  console.log(json);
})();

---

PS for the Auth0 team:

1. Given this was so simple, despite the unsolved threads above, I must ask, are we doing something wrong?

2. Some suggestions to make this even easier:
   a. Give an example of what the “Default Directory” string should be. In our case it was Username-Password-Authentication.
   b. The application/x-www-form-urlencoded parameter format is awkward. Can JSON be also accepted?
   c. The request module has long been deprecated. Would be nice to use node-fetch or a modern HTTP request module for Node.

3. Closed topics just because no answer was given…

   • feel frustrating to those who could give an answer later
   • make it awkward to notify users in those topics if starting a new topic with the solution
   • starting a new thread just to say “Here’s a solution to this old thread” feels clunky and creates clutter in the forum
   • search engines will still direct users to the old topics, without solutions, and those users won’t find the solution given later (IF the user who bothers to start a new thread (the vast majority won’t) links to the old topic, there will be a tiny link at the bottom of the old topic pointing to the new one, but that’s very easy to miss, and doesn’t suggest there’s a solution now; just a related topic)
     • this can easily make users think Auth0 has a limitation, when in fact that was fixed later

   Please reconsider closing topics for no good reason other than X days had passed.

[dan.woda]

Hi @Civility,

Thanks for putting together that write up. It is super helpful for users looking for the same solution, and is something we appreciate greatly. I added links to it in the two topics you mentioned, hopefully we can move those out of the SEO spotlight and move this topic into it.

Let’s talk about the comments from the first thread you linked:

How to obtain user JWT token from username/password?

My feeling is that Auth0 has become a really confusing, messy and over complicated solution. Also, this change was a major change to the workflow and it has not been communicated properly.

How to obtain user JWT token from username/password?

I agree. Auth0 looks and feels painfully over-architected, without simple solutions to common workflows.

This is something that we talk about internally constantly. Finding a balance between a robust, enterprise solution that provides the scalability and extensibility required by large customers; and a simple, intuitive, and efficient solution for builders that want to get up and running ASAP, so they can focus on what matters to them.

Even further, we provide a security product. Some of our features (like the resource owner password grant) can be misused. This is why there are so many warnings and caveats about doing something as seemingly simple as exchanging a credential for a token. We steer customers (particularly ones who want a one-click solution) towards quickstarts and Universal Login.

Any specific feedback you have on how we can further drive that vision forward is always appreciated.

I’ll try and address some of the other feedback you mention regarding the Community:

@Civility

Closed topics just because no answer was given…

We don’t have an automatic closure for unanswered topics any longer. We did this for a period of time but have since stopped closing topics that have no responses.

@Civility

• feel frustrating to those who could give an answer later
• make it awkward to notify users in those topics if starting a new topic with the solution

Simply linking the OP will notify the user of your topic.

@Civility

starting a new thread just to say “Here’s a solution to this old thread” feels clunky and creates clutter in the forum

Old topics often get derailed. For example, the first one you posted very quickly went from a technical question about ROPG to a critique of the general state of Auth0. It is not productive for that topic, and should be a discussion started in a new thread or submitted to our feedback page if appropriate.

In my ideal world, all similar questions would exist in the same thread, but this just simply doesn’t happen. Thread are constantly hijacked as a way to get more eyes on a question by sending out notifications to all users. Dealing with many short threads is much easier than a few less threads with no clear focus.

@Civility

search engines will still direct users to the old topics, without solutions, and those users won’t find the solution given later ( IF the user who bothers to start a new thread (the vast majority won’t) links to the old topic, there will be a tiny link at the bottom of the old topic pointing to the new one, but that’s very easy to miss, and doesn’t suggest there’s a solution now; just a related topic)

• this can easily make users think Auth0 has a limitation, when in fact that was fixed later

We will consider this feedback in our team weekly meeting.

Thanks again for all of the feedback. We appreciate the time you took to go through it.

Best,
Dan