Issue with Refresh Token Acquisition in MSAL Node.js Application

Question

Issue with Refresh Token Acquisition in MSAL Node.js Application

jhirono 20

Github Repo: https://github.com/jhirono/todoMCP

Node.js file for auth: https://github.com/jhirono/todoMCP/blob/main/src/auth-server.js

Issue Description

Our application is unable to obtain a refresh token when authenticating with Microsoft Graph API using MSAL Node.js. Despite explicitly requesting the offline_access scope and forcing consent, the refresh token is not included in the token response.

Environment

MSAL Node.js
Authentication flow: Authorization Code Flow
Application type: Confidential Client (Web application)

// MSAL Configuration
const msalConfig = {
  auth: {
    clientId: process.env.CLIENT_ID,
    authority: `https://login.microsoftonline.com/${process.env.TENANT_ID}`,
    clientSecret: process.env.CLIENT_SECRET
  }
};

// Requested Scopes
const scopes = [
  'offline_access',
  'openid',
  'profile',
  'Tasks.Read',
  'Tasks.Read.Shared',
  'Tasks.ReadWrite',
  'Tasks.ReadWrite.Shared',
  'User.Read'
];

Steps Tried

Azure Portal Configuration

Verified "Allow public client flows" is disabled
Confirmed offline_access permission is explicitly added and admin consent granted
Double-checked all required API permissions

Authentication Parameters

Added prompt: 'consent' to force consent screen
Placed offline_access first in scopes array
Added openid and profile scopes

Different Authority URLs

Debugging Steps

Implemented detailed MSAL logging
Added cache plugin to track token caching behavior
Verified all scopes in token response
Cleared browser cookies and revoked app permissions between attempts

Current Behavior

Successfully receives access token
Successfully authenticates with Microsoft Graph API
Receives all requested scopes EXCEPT offline_access
No refresh token in the response

Expected Behavior

Receive refresh token along with access token
Have offline_access included in granted scopes

Questions for Support

Why is the offline_access scope being dropped from the granted scopes?
Are there any additional configuration requirements for obtaining refresh tokens?
Are there any known issues with refresh token acquisition in this scenario?

Logs

We can provide detailed MSAL logs and token response structure (with sensitive data removed) if needed.

Accepted answer

1 additional answer

Your answer

Answer 1

Goutam Pratti 6,170 Microsoft External Staff Moderator

Hello @jhirono ,

I Understand your application is unable to obtain a refresh token when authenticating with Microsoft Graph API using MSAL Node.js. The refresh token is not included in the token response.As your application is unable to obtain a refresh token when authenticating with Microsoft Graph API using MSAL Node.js. Despite explicitly requesting the offline_access scope and forcing consent, the refresh token is not included in the token response.

MSAL Node, like other MSAL libraries, does not expose refresh tokens for security reasons. Instead, MSAL handles the token refresh process automatically.

If you need to retrieve the refresh token, it is not directly included in the response. Instead, it is stored in the MSAL token cache, which keeps track of tokens for future use. MSAL manages this cache internally, and you can access it when needed using the getTokenCache() method.

To retrieve the refresh tokens and call the User Info Endpoint, refer to the modifications outlined in the document here: StackOverflow link.

As for implementing persistent authentication for your desktop application, I recommend using a conditional access policy with a sign-in frequency that requires periodic authentication. This approach will ensure users can maintain continuous access to the application..

Follow the document for detailed explanation and Implementation of conditional Access policy and Sign in frequency.

For Additional Information: MSAL Refresh Token, Refresh Token Grant

Hope this Helps Let me know if you any additional Queries Happy to assist you further.

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Goutam Pratti 6,170 Reputation points Microsoft External Staff Moderator

2025-03-27T08:16:31.2666667+00:00

Hello @jhirono ,

Following up to see if the above answer was helpful. let us know if you have any queries. Happy to assist you further.
Goutam Pratti 6,170 Reputation points Microsoft External Staff Moderator

2025-03-28T06:43:34.9533333+00:00

Hello @jhirono ,

Following up to see if the above answer was helpful. let us know if you have any queries. Happy to assist you further.
jhirono 20 Reputation points

2025-03-31T04:51:34.2833333+00:00
Thank you. Your solution fixed my issue. I could understand that conditional access is a proper method but in our case, it is a bit hard to implement because of the current un-matured AI MCP. I hope they can support oauth 2.0 in a better way, it is on their roadmap.

This is my AI assisted summary for others.

Understanding the MSAL Refresh Token Approach

MSAL Design Principle: MSAL doesn't expose refresh tokens directly for security reasons. Instead, it handles token refreshing internally through its token cache.

Token Cache: When authentication is successful, MSAL stores tokens (including refresh tokens) in its internal token cache. Instead of directly accessing the refresh token, we should use MSAL's built-in methods.

Confidential Client Flow: For confidential client applications (with a client secret), we should use acquireTokenSilent to get a new access token when needed.

Our Solution

Initial Authentication: We're still using the authorization code flow to authenticate users, which correctly populates the token cache.

Token Refresh: Instead of trying to extract and use the refresh token directly, we now:

Retrieve the user account from the token cache

Use acquireTokenSilent with that account to get a new access token

Fallback Mechanism: If silent token acquisition fails, we redirect the user back to the authentication page.

Key Benefits of This Approach

Security: We're following Microsoft's best practices by letting MSAL handle sensitive tokens.

Simplicity: No need to manage refresh token storage and rotation ourselves.

Reliability: MSAL handles edge cases like token expiration, invalid tokens, etc.

Usage Pattern

Now when your application needs to make an authenticated request to Microsoft Graph:

Check if the access token is still valid

If expired, call your /refresh endpoint

If refresh succeeds, use the new access token

If refresh fails, redirect the user to login again

This approach provides a secure and reliable way to maintain user sessions in your Microsoft Todo MCP application.

Understanding the MSAL Refresh Token Approach

MSAL Design Principle: MSAL doesn't expose refresh tokens directly for security reasons. Instead, it handles token refreshing internally through its token cache.

Token Cache: When authentication is successful, MSAL stores tokens (including refresh tokens) in its internal token cache. Instead of directly accessing the refresh token, we should use MSAL's built-in methods.

Confidential Client Flow: For confidential client applications (with a client secret), we should use acquireTokenSilent to get a new access token when needed.

Our Solution

Initial Authentication: We're still using the authorization code flow to authenticate users, which correctly populates the token cache.

Token Refresh: Instead of trying to extract and use the refresh token directly, we now:

Retrieve the user account from the token cache

Use acquireTokenSilent with that account to get a new access token

Fallback Mechanism: If silent token acquisition fails, we redirect the user back to the authentication page.

Key Benefits of This Approach

Security: We're following Microsoft's best practices by letting MSAL handle sensitive tokens.

Simplicity: No need to manage refresh token storage and rotation ourselves.

Reliability: MSAL handles edge cases like token expiration, invalid tokens, etc.

Usage Pattern

Now when your application needs to make an authenticated request to Microsoft Graph:

Check if the access token is still valid

If expired, call your /refresh endpoint

If refresh succeeds, use the new access token

If refresh fails, redirect the user to login again

This approach provides a secure and reliable way to maintain user sessions in your Microsoft Todo MCP application.

Answer 2

Bruce (SqlWork.com) 77,851 Volunteer Moderator

Because you are using a client secret, you don’t get a refresh token. What do you need it for? Your code has the secret and can get a new access token without using a refresh token. Refresh tokens are for when the app can not be trusted with having login credentials and must use the clients.

jhirono 20 Reputation points

2025-03-25T02:19:51.4733333+00:00
Thank you for the clarification about client secrets and refresh tokens. However, our use case is slightly different:

We're building a desktop application that needs to maintain user authentication even when the application is closed and reopened.

While we're using a client secret for the initial OAuth flow (as recommended for security), we need to persist the user's session across application restarts without requiring them to log in each time.

Our current approach requires storing the access token locally, but these tokens expire in a short time (usually 1 hour). Without a refresh token, our users would need to re-authenticate every time the access token expires.

Is there a recommended pattern for maintaining persistent authentication in a desktop application scenario?Thank you for the clarification about client secrets and refresh tokens. However, our use case is slightly different:

We're building a desktop application that needs to maintain user authentication even when the application is closed and reopened.

While we're using a client secret for the initial OAuth flow (as recommended for security), we need to persist the user's session across application restarts without requiring them to log in each time.

Our current approach requires storing the access token locally, but these tokens expire in a short time (usually 1 hour). Without a refresh token, our users would need to re-authenticate every time the access token expires.

Is there a recommended pattern for maintaining persistent authentication in a desktop application scenario?
jhirono 20 Reputation points

2025-03-25T22:24:00.4233333+00:00
Thank you for the clarification about client secrets and refresh tokens. However, our use case is slightly different:

We're building a desktop application that needs to maintain user authentication even when the application is closed and reopened.

While we're using a client secret for the initial OAuth flow (as recommended for security), we need to persist the user's session across application restarts without requiring them to log in each time.

Our current approach requires storing the access token locally, but these tokens expire in a short time (usually 1 hour). Without a refresh token, our users would need to re-authenticate every time the access token expires.

Is there a recommended pattern for maintaining persistent authentication in a desktop application scenario? We considered these options:

Store the client secret locally - but this seems less secure than storing a refresh token

Switch to public client flow - but this might be less secure for initial authentication

Implement a hybrid approach - use confidential client for initial auth but get refresh tokens for persistence

Which approach would you recommend for our desktop application use case?"Thank you for the clarification about client secrets and refresh tokens. However, our use case is slightly different:

We're building a desktop application that needs to maintain user authentication even when the application is closed and reopened.

While we're using a client secret for the initial OAuth flow (as recommended for security), we need to persist the user's session across application restarts without requiring them to log in each time.

Our current approach requires storing the access token locally, but these tokens expire in a short time (usually 1 hour). Without a refresh token, our users would need to re-authenticate every time the access token expires.

Is there a recommended pattern for maintaining persistent authentication in a desktop application scenario? We considered these options:

Store the client secret locally - but this seems less secure than storing a refresh token

Switch to public client flow - but this might be less secure for initial authentication

Implement a hybrid approach - use confidential client for initial auth but get refresh tokens for persistence

Which approach would you recommend for our desktop application use case?

Share via

Issue with Refresh Token Acquisition in MSAL Node.js Application

1 additional answer

Your answer