Invalid credentials when hitting the /userinfo endpoint

Greetings!
I’m getting my head around user auth in React by building a simple app with Auth0 features. So far so good. The problem starts when I try to hit the /userinfo endpoint. I’m using Superagent to make my API request.

import auth0 from 'auth0-js';
import request from 'superagent';
import { auth0Globals } from '../config.js';
import { getAccessToken } from './AuthService';

function userProfile(auth) {
	request
		.get( 'https://' + auth.CLIENT_DOMAIN + '/userinfo' )
		.set( 'authorization', 'Bearer ' + getAccessToken() )
		.end( function(err, res) {
			if ( err ) {
				console.log(err);
			}
		});
}

const user = userProfile(auth0Globals);

The server responds with a 401 error, citing Invalid Credentials as the culprit. I’m getting this in the browser as well as in Postman with Auth0’s pre-built GET request for /userinfo. This leads me to believe that my client is probably set up incorrectly, but I’m also finding that I can’t access user info for the example client that comes with new Auth0 accounts.

Any ideas for what I might be doing wrong? I can confirm that auth.CLIENT_DOMAIN and the getAccessToken() function are returning data and that the data is correct.

I could not reproduce this situation, the 401, unless I provided an incorrect access token.

The access token you’re using is an opaque access token, around 16 characters, or a JWT access token? If it’s a JWT access token consider including the header and payload components in your question (you can redact the values of any claims you deem sensitive).

In addition, it may be useful to update the question with the exact contents of the WWW-Authenticate response header you get along with the 401.

I could replicate this problem while having a rule modifying the scope claim of the access token of the open id token. When I disabled the rule everything started working again. This was not happening yesterday and I don’t see any other feasible explanation besides a change in Auth0 code since nothing changed on my rule code or lock config. Maybe you were doing something similar in a rule?