Invalid token when accessing Authorization Extension API

Help
1

This is exactly the same symptom we were seeing when calling /userinfo yesterday (/userinfo suddenly results in 401, unauthorized (CRITICAL!) - Auth0 Community) except now it’s happening when calling the Authorization Extension API on route /users/{userId}/groups?expand=1

Getting the error:

{
    "statusCode": 401,
    "error": "Unauthorized",
    "message": "Invalid token",
    "attributes": {
        "error": "Invalid token"
    }
}

This is code that’s been working for months and there was no recent changes.

2

I have been getting the same error since 6hrs ago. This has forced me to undo a lot of code in an effort to get to the root cause of the issue. Sadly I realized the that the error wasn’t from my end.
There was a fix made to the system High Error Percentage in users search (US) • Auth0 Status Page

![alt text][1]

I am just wondering when the service will be up and running again?

3

I’m getting same error. I figured why the extension is rejecting the tokens by inspecting the code. At server/plugins/auth.js#80:

if (decoded.payload.azp) {
    return callback(Boom.unauthorized('Invalid token', 'Token'), null, null);
}

It rejects tokens containing azp claim. Since yesterday tokens generated with grant type client_credentials contain this claim. Sadly, I don’t know how to fix it.

UPDATE: A PR has been submitted on the extension’s repository which should resolve the problem: checking token's gty insteas of azp by zxan1285 · Pull Request #168 · auth0/auth0-authorization-extension · GitHub

4

UPDATE (Resolution): The issue should now be addressed across the board. The preliminary fix (in order to allow for a quicker fix) did not depend on changing the Authorization Extension code so if you look at the linked PR you may still see it open for a while. There will likely be changes in the extension in order to better support the requirement that originally triggered the error, but any future changes will now have in consideration the root cause of the issue so any changes will be transparent to you. If you still experience the issue let me know (or if you can confirm that it’s already resolved then it would even be better).

Sorry for the radio silence; this question was quickly followed by an answer that diminished the visibility of the question (a completely unanswered question will sit on the unanswered queue which gives it greater visibility).

If you’re reading this, in the future please avoid providing answers that are not in fact solutions to the problem and just contain additional information or state that you’re also experiencing the same issue; please use comments for that!

If you’re the original author of the question you can proactively ask those answers to be moved to comments.

Moving to what’s important; the fact there is indeed an issue. As @maxime.ribera already noted we are aware of the issue and there is already a PR with a fix. However, the updated code still needs to be deployed and reach you so we are also considering if there’s quicker alternatives to address this. As additional information you can also now keep track of updates to this situation through the following incident.

5

I have been getting the same error since 6hrs ago. This has forced me to undo a lot of code in an effort to get to the root cause of the issue. Sadly I realized the that the error wasn’t from my end.
There was a fix made to the system High Error Percentage in users search (US) • Auth0 Status Page

![alt text][1]

I am just wondering when the service will be up and running again?

6

I’m getting same error. I figured why the extension is rejecting the tokens by inspecting the code. At server/plugins/auth.js#80:

if (decoded.payload.azp) {
    return callback(Boom.unauthorized('Invalid token', 'Token'), null, null);
}

It rejects tokens containing azp claim. Since yesterday tokens generated with grant type client_credentials contain this claim. Sadly, I don’t know how to fix it.

UPDATE: A PR has been submitted on the extension’s repository which should resolve the problem: checking token's gty insteas of azp by zxan1285 · Pull Request #168 · auth0/auth0-authorization-extension · GitHub

7

@jmangelo thanks for the update

8

@jflitton @dmigwi the situation should now be resolved across the board; you can see my updated answer for additional details.

9

Confirmed, this is working again for all of our tenants. Thanks!

10

I’m not 100% sure this incident relates to our issue, but the complete lack of detail from auth0 regarding:

  1. The cause of the issue
  2. The nature of the fix

makes it impossible to say one way or the other. So either this was a separate issue or their fix didn’t work.

11

@jflitton We are now stuck with no official information on:

  1. What is fix they made?
  2. The anticipated down time.
  3. Possible effect to our data …
    The best we can do is to keep trying the endpoints or visiting this page to know if all is well…
12

@maxime.ribera did you use the Public and the Private Keys provided by auth0 to regenerate the HS256 encoded token?

13

Could you share how you were able to ascertain the issue above? That might be our temporary solution as we wait for the system to be fixed.

14

Yes we use the public and private key generated by Auth0, but with RS256 algorithm

15

@maxime.ribera I maintained your post as an answer because the update with the PR link does indeed qualify as a solution/workaround/outcome/conclusion of the original question. Also, great analysis of the problem and appreciate the troubleshooting skills, however, in the future include this as comments first and only move to an answer when it does provide some closure to the question (see the reasoning behind this on my other answer).

16

Sorry, my bad. As a new Auth0 user, this is the first time i use this forum.
I moved my answer as a comment, as you mentionned the PR in your reply.
Thank you for the incident status, btw i’m using the EU preview, if that can help.

17

@maxime.ribera we are still working on the situation in order to resolve it across the board, but I have some indications that in EU preview it should likely already be resolved. If you can confirm that would be great.

18

@jmangelo i can confirm that the authorization API is working again on EU preview :slight_smile: Thank you !

The ‘azp’ field has been removed from tokens for grant type ‘client_credentials’.

But we still need a fix on the extension to update the way for restricting access tokens to client credentials only (the PR subject).

19

Yes, the quickest way to address this for now was to not touch the extension, but going the other way around. The azp claim will be back, but this time the Authorization extension will already be expecting it as the requirement needing to be met by the extension can be done differently like you mentioned.