Configure Auth0 API App to accept id_token instead of access_token (legacy)

Help
1

First let me start by saying I understand the difference between access_tokens and id_tokens, and that it is strongly recommended to use access_tokens for authorizing against an API.

Currently I’m working with a legacy application that uses the id_token to access APIs in an old backend. I am now building a new backend that needs to be compatible with the old one, and I need to write tests in the new backend that are compatible with the end-to-end flow of the legacy backend, which, again, uses the id_token to authorize against APIs.

How do I configure my Auth0 API application to accept id_tokens in place of access tokens? Any help would be appreciated, I have scoured the documentation and there does not seem to be a way to do this. I have also looked at the quick start guides and there is no support on this.

2

There’s not docs around this, as as you said, it’s definitely not a recommended way. However, your backend accepting the ID token is purely based on the logic that you put in your backend for the JWT verification. This means, it depends what claims in a token you’re verifying, such as issuer, audience, exp etc. beside verifying the signature of course.
So, there’s not much to configure on Auth0 end but more on your backend side in regards to the JWT verification.

3

Ah, I see. So by default the id_token would be accepted, but how I verify that the actual id_token is legit is up to how I configure the JWT validation settings. Makes sense. I’ll give this a shot.

Thank you!

EDIT
Question @Mathias, does this mean that my API will automatically allow id_tokens? When I try to pass an id_token to my API, I get an error regarding an invalid signature. My token is HS256 and signed with a Signing Secret.

This is my current setup:

static void AddAuthentication(IServiceCollection serviceCollection)
    {
        IdentityModelEventSource.ShowPII = true;
        serviceCollection.AddAuthentication(options =>
        {
            options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
            options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;

        }).AddJwtBearer(options =>
        {
            options.TokenValidationParameters = new TokenValidationParameters
            {
                RequireSignedTokens = true,
                ValidateAudience = true,
                ValidIssuer = _auth0Configuration.Domain,
                ValidAudience = _auth0Configuration.Audience,
                IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_auth0Configuration.SigningSecret)),
                ValidateLifetime = false,
                ValidateIssuerSigningKey = true,
            };
        });
    }
2 Likes
4

Update on this, I was going back and forth with @mathiasconradt re: getting my id_token to work re: authorizing against my API, but we still can’t seem to figure out why the token id_token itself is not working.

When issuing a request against my API with an id_token, I receive the following response:

Bearer error="invalid_token", error_description="The signature is invalid"

The token is being signed with the Signing Secret provided in the API that I have configured with Auth0. I have tried omitting RequireSignedTokens and ValidateIssuerSigningKey to see if that fixes the issue, yet I still get the same error. If I omit the IssuerSigningKey completely, I get the following error:

Bearer error="invalid_token", error_description="The signature key was not found"

Presumably because the id_token doesn’t get signed, which tells me that there must be a problem with the signature itself. Is there another way one should be signing the id_token besides the Signing Secret, maybe?

Also, it should be noted that this is a valid JWT token (confirmed on JWT.io) and that the Signing Secret is coming up as invalid. The Client Secret from the corresponding application seems to come up as valid though, which is confusing if I’m hitting my API that accepts HS256 JWTs that are supposed to be signed by the Signing Secret.

Any help is appreciated.

Thanks!

5

Another update here, I switched from signing my id_token with the provided Signing Secret to signing it with the ClientSecret, that made my invalid_signature issue go away. I was then receiving an invalid_audience error, and realized that because the audience for id_tokens is different than it is for access_tokens, I switched that.

Now the id_token has the ClientId set as the audience and is being signed with the ClientSecret. I’m getting a brand new error when trying to hit my API at this point:

Bad HTTP authentication header format

The JWT comes back as valid with a valid signature (via JWT.io) but my API is still rejecting. Any ideas?