Make it easier to refresh tokens on the server without distributed cache for better serverless support

[mastoj]

Core Library

MSAL Node (@azure/msal-node)

Wrapper Library

Not Applicable

Public or Confidential Client?

Confidential

Description

More and more people are using next.js, but this should also be applicable to a asp.net application following the same pattern, but I will take it from the next.js point of view.

In next.js, it is very common to do the token exchange on the server and less work on the client. This is all good and something that is fairly easy to set up. What is not easy is the refresh of tokens. I actually expected to get some refresh token in the response that I could set on a refresh_token cookie, but that does not seem to be the case. Instead it seems like this example, https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples, focus on setting up a cache that is durable, but in my mind that just leads to extra complexity.

What is the reason to not just expose the refresh token and then in frameworks like next.js, the server can request new tokens using the refresh token in a middleware if needed before executing a function. This way it would be much easier to have the authorize callback function in a serverless environment for example.

I think some of the steps trying to simplify the flows have made it more complex than needed and would love to see a simpler version without as many abstractions.

The flow I picture in my head

• Login client request -> Server - responds with authorize url
• User follows authorize url and gets code back
• User make a request with code -> Server - responds with relevenant cookies, one should be refresh_token
• When access token expires, but refresh token is valid -> middleware refreshes the access token before executing a function