Is there a way to send id token to the server instead of access token for AJAX request?

Hi,

We are currently migrating a web app to using Okta SSO, it uses ASP.NET Web API 4 backend, with Angular JS front end. We frequently needs to make AJAX requests to an end point, and the only way to make it work(as I know of) is to add an ‘Authorization’ header for JWT bearer in the request like this:

var accessToken = data.tokens.accessToken;
$.ajax({
    dataType: "json",
    headers: {
        Authorization: 'Bearer ' + accessToken.accessToken
    },
    url: url
})

However, the access token contains very few information, only the email address is useful. The id token, on the other hand, contains other useful information such as the user’s name and preferred username, which are needed to populate ASP.NET identity claims.

So I wonder, is there a way we can send the id token in the header information instead of access token? If so, how to do this? Or is the only workaround is to copy claims from id token to access token? Thx.

You should not be using ID tokens for Authorization, you should be securing your API with Access Tokens, as you are currently. See ID Tokens vs Access Tokens

If your backend already has the access token, it could make a request to the Userinfo endpoint to retrieve user profile details. Another option would be to pass additional information within the Access Token payload by creating custom claims on your custom authorization server.

Hi Andrea,

Thanks for your response. If I understand correctly, id tokens are supposed to be used exclusively on the client side, and shouldnt be sent to server for authorization? The thing is that the access token has only email address information and nothing else, while ASP NET Identity requires other information such as name, preferred_username and roles. I am not sure its a good idea to make a request to user info endpoint from the server side, as I fear it will be incredibly slow. Custom authorization server sounds like a better solution, if our backend devs can be convinced to go this approach. I also wonder if it is possible to add claims from id token into access token from the client side?

you won’t be able to modify the Access token and still have it accepted by your API as it is signed by Okta (unless of course you configure your backend to be protected by JWTs you issue instead).

I agree, having to make an additional request from the server to get this information will introduce latency which is not ideal, so if these details are required on the server side and you want them to always be sourced from Okta (as opposed to also storing/caching them on your side, to limit the userinfo calls and linking them to a value you already receive in the access token), creating Custom Claims to appear in the access token is likely the best approach for your use case.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.