IDX10501: Signature validation failed. Unable to match key, Angular frontend, .core 3 backend

I have an angular app where I use octa login, this seems to work fine, as I log in and get a couple of tokens.

When I then send the accessToken to my backen API, I get the IDX10501 error while authenticating it. If I use to decode the token, I can see that I do indeed have a different key.

In my angular app I’m using “@okta/okta-signin-widget”: “^5.16.0”,
I’m using a fairly default config

widget = new OktaSignIn({
    authParams: {
       scopes: ['openid', 'email', 'profile'],
    issuer: `${environment.oktaDomain}/oauth2/default`,
    clientId: environment.oktaClientId,
    redirectUri: window.location.origin + '/login/callback',

In my dotnet core 3.1 app I have the following code:

                .AddJwtBearer(options =>
                    options.Authority = $"{Configuration["Authentication:OktaDomain"]}/oauth2/default";
                    options.Audience = "api://default";

Using developer tools in chrome I can see that the showSignInAndRedirect results in a call like this:

I’ve tried changing baseurl, issuer and added issuer to authParams, but none of them seems to change the authorize url that is called to “/oauth2/default/v1/authorize?client_id=” witch I think is the right URI.

IS the authorize url the issue? How do I fix this?

Try removing the issuer setting in your widget. By default, the widget will try to use the Default Auth Server (note that the use of this server will be dependent on your org features), so you shouldn’t need to set it there.

I’ve tried with just issuer, just baseUrl and both of them. I’ve also tried setting baseUrl + authParms.issuer. All of these goes against the
And get’s the wrong key.

I’ve been able to manually verify the JWT token from the front end using the key’s I get from:
But I’m unable to get a JWT token from the front end widget with the key that corresponds to this:

This probably won’t help @hpevjuonyx but are you using the default Okta authorisation server or a custom one? Maybe its using one instead of the other?

Perhaps also verify the angular generated URLs are hitting the correct auth server and endpoints?

1 Like

I’m trying to use the custom default authorization server, but no matter what I do, the octa sign in widget seems to keep hitting the default authrization server. Or in other words:

Widget calls this:

I think it should be calling this:

If you’re using a self-hosted widget, can you try using the following for your widget config?

var signIn = new OktaSignIn(
        baseUrl: "",
        clientId: CLIENT_ID,
        redirectUri: REDIRECT_URI,
            issuer: "",
1 Like

Key bit is probably ensuring the custom auth server identifier is in your base URL like:

So the URL generated by

Should look something like:

Need to make sure the okta domain for your custom auth server uri is in your common Okta SDK config so it can resolve the /keys endpoint which should also look something like

I’m not using a self-hosted widget, but I did try your code anyway, and I’m still getting the wrong authorize url, and thus also the wrong key.

I’m trying to use the default custom authorization server (ie my id is “default”)

I don’t know where in my angular code you are refering to, can you give me a code example using the okta widget?

Somewhere in your angular code you should have a config object defined which looks like @andrea 's example above. If you grabbed the Okta angular SDK from github and are following the guide there (GitHub - okta/okta-angular: Angular SDK for Okta's OIDC flow) the config seems to be in myApp.module.ts

You mean this object from my first post?

As I’ve been trying to say, I’ve tries several variants of this config object but I always get the wrong keys/ authorize URL

  • Only issuer
  • Only baseUlr
  • baseUrl with authParams.issuer
  • baseurl with issuer
  • baseurl with issuer and authParams.issuer
    I’m using these versions
    "@okta/okta-angular": "^5.1.0",
    "@okta/okta-auth-js": "^5.9.0",
    "@okta/okta-signin-widget": "^5.16.1",

Did you try putting the issuer option within the authParams object?

What does ${environment.oktaDomain} resolve to? Does it have your custom Auth Server identifier?

yes, makes no difference

domain = devtechonyxcentersource

It needs to resolve to

So no difference with that URL?

Re-reading your first post, it sounds like you’re doing online introspection of the token to validate it. The other thing to double-check if your backend API is able to authenticate correctly.

Note: The /introspect endpoint requires client authentication. Most client authentication methods require the client_id and client_secret to be included in the Authorization header as a Basic auth base64-encoded string with the request. See the Client authentication methods section for more information on which method to choose and how to use the parameters in your request.