In the azure active directory documentation it states:
idToken: id_tokens are sent to the client application as part of an OpenID Connect flow. They can be sent along side or instead of an access token, and are used by the client to authenticate the user.
accessToken: Access tokens enable clients to securely call APIs protected by Azure
I am using msal to log the user into my vue application (single page web app) and try to acquire accessToken to my REST API.
My goal is to separate the auth flow of the frontend from the backend that way in the future several client applications can access the REST API through accessTokens.
When logging in, I get prompted a permission popup and afterwards receive both an idToken token.idToken.rawIdToken and an accessToken token.accessToken in the token response of msal.aquireTokenSilent(config).
I am using passport and passport-azure-ad with the BearerStrategy to validate the accessToken as a middleware. If I pass the token.accessToken with the Authorization Bearer header, I receive a authentication failed due to: invalid signature error. If I pass the
token.idToken.rawIdToken instead, I receive authentication failed due to: jwt issuer is invalid if I set validateIssuer: true in the bearer strategy config.
First, I want to find out which token would be the one to use? Both are valid jwt token (https://jwt.ms/) but they contain different fields. I guess as of right now the idToken sounds more promising but I am not sure if it is the way to go as I would need to specify the clientId of the frontend as the audience field in the backend, otherwise it throws authentication failed due to: jwt audience is invalid. So this is not the way to go for multiple clients, right?
Advertisement
Answer
You can use access tokens issued by AAD to secure your own custom web APIs. Note, that you must first create a custom scope, and then have the user consent to that scope. Once you have done that, your application will be issued a token for that scope (access tokens are issued per resource, meaning you can’t protect your custom Web API with a token intended for MS Graph, for example).
See my comment here for more info.