OAuth access and refresh tokens are missing from my request headers after authentication

Question

I am deploying a webapp using Azure App Service which requires authorization to an API (also been deployed as an App Service) on behalf of the user.

According to various tutorials I have followed, after setting up Azure AD authentication, the following tokens should be accessible from the /.auth/me endpoint and passed through as headers on the request:

X-MS-TOKEN-AAD-ID-TOKEN
X-MS-TOKEN-AAD-ACCESS-TOKEN
X-MS-TOKEN-AAD-EXPIRES-ON
X-MS-TOKEN-AAD-REFRESH-TOKEN

However, I am only receiving X-MS-TOKEN-AAD-ID-TOKEN.

I have added the offline_access scope as required on my app, as well as the api://<API_ID>/user_impersonation scope.

Answer 1

Hello @James Palmer , and thanks for sharing your solution. I'm reposting it here so it can be accepted and feedback provided. This will help others experiencing similar issues to find your answer faster:

For anyone coming to this with the same issue, the reason for me was because my IDP did not have access to my client secret; I created my app registration before my app service, rather than at the same time. Therefore the client secret was not stored as the MICROSOFT_PROVIDER_AUTHENTICATION_SECRET application setting, nor applied automatically to the identity provider I added to my app service. To resolve this I took the following steps:

1. Generated a new client secret from my app registration
2. Copied this into an application setting named MICROSOFT_PROVIDER_AUTHENTICATION_SECRET
3. Went to the authentication panel for my app service, and clicked on the Edit icon on my identity provider
4. Set Client secret setting name to MICROSOFT_PROVIDER_AUTHENTICATION_SECRET
5. After saving these settings, I can now access the full set of headers

Answer 2

For anyone coming to this with the same issue, the reason for me was because my IDP did not have access to my client secret; I created my app registration before my app service, rather than at the same time. Therefore the client secret was not stored as the MICROSOFT_PROVIDER_AUTHENTICATION_SECRET application setting, nor applied automatically to the identity provider I added to my app service.

To resolve this I took the following steps:

1. Generated a new client secret from my app registration
2. Copied this into an application setting named MICROSOFT_PROVIDER_AUTHENTICATION_SECRET
3. Went to the authentication panel for my app service, and clicked on the Edit icon on my identity provider
4. Set Client secret setting name to MICROSOFT_PROVIDER_AUTHENTICATION_SECRET
5. After saving these settings, I can now access the full set of headers.

Answer 3

If you are not receiving the expected OAuth access and refresh tokens in the request headers after authentication, there are a few things you can check:

Verify the requested scopes: Ensure that you have correctly configured the requested scopes for your application. Make sure that you have included the offline_access scope to request a refresh token and any other required scopes for accessing the API.

Check the token configuration: In the Azure portal, navigate to your Azure AD app registration (used for authentication) and review the token configuration. Ensure that the access tokens and refresh tokens are enabled for your application. Also, verify that the token lifetimes are set appropriately to allow for the desired expiration and refresh periods.

Test with different endpoints: Instead of using the /.auth/me endpoint, you can try using the /.auth/refresh endpoint to obtain the refresh token. The /.auth/refresh endpoint provides a refresh token directly without requiring an explicit refresh request.

Verify consent and permissions: Make sure that the user has consented to the requested scopes during the authentication process. If the user has not consented, the requested tokens may not be issued.

Review application code: Double-check your application code to ensure that you are correctly extracting and passing the tokens from the /.auth/me endpoint to the request headers. Confirm that the required headers are being set properly.

If the issue persists after checking these steps, it may be helpful to review the specific authentication configuration and code implementation for your application to identify any potential issues or misconfigurations.