Add access token to user details endpoint (/.auth/me)

[colinansah]

Is your feature request related to a problem? Please describe. I'm using a custom identity provider and have the rolesSource set in the staticwebapp.config. Whenever a user logs in, a request gets sent to "/api/GetRoles" to assign roles to a user. All of this works perfectly and whenever I go to "/.auth/me" I have access to the roles, claims etc of the user.

The problem I'm facing is that the access token seems to be missing from the user details endpoint, and it's not a case of my identity provider not supplying the access token. I've setup azure application insights to inspect the request sent to "/api/GetRoles", and the principal sent in the body of the request clearly contains the access token. It's frustrating that the only place the access token is accessible, is an endpoint that must return "roles" and is not accessible after the initial call when a user logs in.

Describe the solution you'd like I would like for the access token to be present whenever I send a request to the user details endpoint (/.auth/me).

Describe alternatives you've considered I tried setting up a function called GetAccessToken that would retrieve the access token from the "x-ms-client-principal" header, but whenever I made a request to /api/GetAccessToken, the only information available in the "x-ms-client-principal" header is an object with the following properties:

• IdentityProvider
• UserId
• UserDetails
• UserRoles

There is unfortunately no access to claims or the access token in this client principal, like there is in the request body of the "/api/GetRoles" call.

[mkarmark]

Can we get more details on why you would like the access token to be exposed? We have intentionally hidden in from the /.auth/me output for security reasons but can consider exposing it there if there is sufficient reason to expose it.

[colinansah]

The access token needs to be sent with every request to our services (APIs on the same domain as the SWA) in order for the users to get access to their resources. Perhaps an option to set a httponly cookie with the token is more suited for this situation?

[ivancavlek]

@mkarmark,

What @colinansah is saying is that access token doesn't have to specifically be visible in /.auth/me, but should be available whenever we call an api function and that it can be derived from x-ms-client-principal.

That would help enormously to reuse the existing access token and not login users twice, once to SWA and to e.g. MSAL. There are already issues created considering this problem. Besides, when using Blazor and MSAL with Microsoft Graph and ASP.NET Core as a backend, access token is exposed and I can easily get access to it. So, what is the difference in exposing it here?

Please, consider enabling this option or propose us an alternative.

[ramseytm]

Hello @mkarmark, just chiming in that we're running into the same issue and this would be enormously helpful for our scenario where we have a managed function app and need to utilize the access token for graph calls outside of the GetRoles request.

[kevindehoux]

Hi, same problem here. I thought that includes enough scopes in the loginParameters would fixed the problem but not, anyone know how to deal with this problem ? Personnaly i need accessToken to perform call on graph to retrieve avatar of users

[miguelEsteban]

Same problem here. In my case we use custom openId (duende identity server), need acces token to invoque a rest api protected by this IDP.

[BernhardRode]

Same here

[ivancavlek]

@mkarmark,

In two months time multiple people requested this option in this conversation only (there are other conversations that request the same thing). This is also one of the issues with the highest number of requests.

Can you please assign somebody on this task or open a discussion or at least provide us with an alternative?

[axc450]

This needs to be added ASAP.

I am currently migrating a SPA from Azure Web App (running in pm2 SPA mode) to Azure SWA and this is a huge blocker as my frontend can no longer communicate with the API. The API itself is protected with Easy Auth and to get the access token for the API, I currently follow the Microsoft provided instructions: https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-oauth-tokens#refresh-auth-tokens

From your client code (such as a mobile app or in-browser JavaScript), send an HTTP GET request to /.auth/me (token store must be enabled). The returned JSON has the provider-specific tokens.

Why does the /.auth/me endpoint for a SWA not contain the access token that is required to talk to my API and looks completely different to the Azure Web App's /.auth/me endpoint?? I don't really see how this is a security concern when Azure Web App can do this just fine.

Unless I have misunderstood, I don't think there is any way currently for my SWA to talk to the API and therefore I cannot use Azure SWAs. Does anyone know of a workaround? 🙁

[diberry]

@cephalin @anthonychu FYI

[Rutix]

This needs to be added ASAP.

I am currently migrating a SPA from Azure Web App (running in pm2 SPA mode) to Azure SWA and this is a huge blocker as my frontend can no longer communicate with the API. The API itself is protected with Easy Auth and to get the access token for the API, I currently follow the Microsoft provided instructions: https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-oauth-tokens#refresh-auth-tokens

From your client code (such as a mobile app or in-browser JavaScript), send an HTTP GET request to /.auth/me (token store must be enabled). The returned JSON has the provider-specific tokens.

Why does the /.auth/me endpoint for a SWA not contain the access token that is required to talk to my API and looks completely different to the Azure Web App's /.auth/me endpoint?? I don't really see how this is a security concern when Azure Web App can do this just fine.

Unless I have misunderstood, I don't think there is any way currently for my SWA to talk to the API and therefore I cannot use Azure SWAs. Does anyone know of a workaround? 🙁

What @colinansah did in the end (which is really ugly but we see no other way) is to add the access token as a role and then retrieve it from there. The only big issue with this is expiration I think.

@anthonychu @mkarmark @Reshmi-Sriram any update on this?

[thjaeckle]

I also stumbled upon this issue - I wanted to access the "Microsoft Graph API" (for which I need an access token) in order to e.g. fetch the user's profile photo for showing the user account. Linked Stackoverflow question: https://stackoverflow.com/questions/74641417/how-to-get-access-token-in-azure-static-web-app-for-authenticating-at-microsoft The suggestion from an Microsoft Graph specialist was to get rid of the built-in SWA auth mechanism and use the MSAL library instead. I however would want to prevent reinventing the complete auth* when SWA already has that aspect covered.

@Rutix regarding your mentioned workaround: Adding the access token as a custom role would be possible by setting user roles programatically? That would indeed be a hack which would lead to far worse security issues.

How about making it configurable in the "staticwebapp.config.json" whether to inject the access_token or not in "/.auth/me"? Or would it be an option to provide an additional endpoint for retrieving the token, e.g. "/.auth/token"? That could - by default - also not be enabled and only enabled via specific configuration.

[jassent]

To add some fuel to this fire...The Create a Function for Assigning Roles documentation shows the desired accessToken being issued by the aad endpoint to the static web app but it actually isn't. I tried both the V1 and V2 endpoints. The sample payload from Azure AD shows the accessToken which if were correct would resolve this issue.

[ivancavlek]

@annikel, @anthonychu, @vivekjilla, @mkarmark, @Reshmi-Sriram Can we, please, have an update on this? Is anybody assigned to this? Is it in the works? When can we expect results? Microsoft is strongly recommending this technology, but, unfortunately, I see only problems with tokens and claims with SWA. Are they going to be worked on? My production dates are closing and I need to know (as many others) can we rely on this technology. Can you at least recommend/make a temporary workaround?

Has anybody else made a workaround? Can we save the token to the database after calling GetRoles? Will it last for the duration of a login?

An update would be appreciated.

[thjaeckle]

Has anybody else made a workaround? Can we save the token to the database after calling GetRoles? Will it last for the duration of a login?

I tried the mentioned workaround returning the token as custom role. That initially works, however once the token is expired, you won't get a new one - as the "getRoles" function is only called once for the login. You also don't get a refresh token in the backend function, so once the initial token is expired, your user has to logout and login again in order to get a new valid token. So I undid the workaround again and have not yet found a simple solution for that in SWA.

[jassent]

Has anybody else made a workaround? Can we save the token to the database after calling GetRoles? Will it last for the duration of a login?

I tried the mentioned workaround returning the token as custom role. That initially works, however once the token is expired, you won't get a new one - as the "getRoles" function is only called once for the login. You also don't get a refresh token in the backend function, so once the initial token is expired, your user has to logout and login again in order to get a new valid token. So I undid the workaround again and have not yet found a simple solution for that in SWA.

Can you confirm how long it persists before expiring? I have had an static app w/ roles set by GetRoles for 24+ hours and the roles seem to maintain in the claims.

[thjaeckle]

Has anybody else made a workaround? Can we save the token to the database after calling GetRoles? Will it last for the duration of a login?

I tried the mentioned workaround returning the token as custom role. That initially works, however once the token is expired, you won't get a new one - as the "getRoles" function is only called once for the login. You also don't get a refresh token in the backend function, so once the initial token is expired, your user has to logout and login again in order to get a new valid token. So I undid the workaround again and have not yet found a simple solution for that in SWA.

Can you confirm how long it persists before expiring? I have had an static app w/ roles set by GetRoles for 24+ hours and the roles seem to maintain in the claims.

How long the token is valid before expiring depends on the used authentication provider (and likely even the configuration of e.g. the Azure AD tenant if Azure AD is used).

I observed that the "custom roles" are only calculated when explicitly logging out and in again - I did not if there is also a time-based re-calculation of the roles.

[Rutix]

Has anybody else made a workaround? Can we save the token to the database after calling GetRoles? Will it last for the duration of a login?

I tried the mentioned workaround returning the token as custom role. That initially works, however once the token is expired, you won't get a new one - as the "getRoles" function is only called once for the login. You also don't get a refresh token in the backend function, so once the initial token is expired, your user has to logout and login again in order to get a new valid token. So I undid the workaround again and have not yet found a simple solution for that in SWA.

Can you confirm how long it persists before expiring? I have had an static app w/ roles set by GetRoles for 24+ hours and the roles seem to maintain in the claims.

How long the token is valid before expiring depends on the used authentication provider (and likely even the configuration of e.g. the Azure AD tenant if Azure AD is used).

I observed that the "custom roles" are only calculated when explicitly logging out and in again - I did not if there is also a time-based re-calculation of the roles.

Yes this is the problem we have ran into so the workaround is not only dirty but also unusable. The people I spoke with that have it working all rolled the auth manually and didn't use easy auth. Which is a major shame since you lose all benefits.

[dmbuk]

I can see that access token is injected in the request headers as x-ms-auth-token when calling API function from the app. However, it has the target function as the audience, so Graph API requests fail with "Access token validation failure. Invalid audience."

[mcraiha]

This feature would also help our current project. Even another endpoint (e.g. auth/me/token ) would be enough.

[sparlampe]

We have a static web app. Further we configured a custom authentication as described in the following. https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-custom?tabs=openid-connect

The static web app needs to consume an API protected by the above configured identity provider, but the tokens issued by the idp are not available. Please make the original tokens available like they are available for the pre-configured providers. https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-oauth-tokens

At the moment the requests forwarded to the linked function app have the following headers, none of which authorizes access to the resources provided by this web service.

AppServiceAuthSession StaticWebAppsAuthCookie x-ms-auth-token x-ms-client-principal-name x-ms-client-principal-id x-ms-client-principal-idp x-ms-client-principal

[schepersk]

To add some fuel to this fire...The Create a Function for Assigning Roles documentation shows the desired accessToken being issued by the aad endpoint to the static web app but it actually isn't. I tried both the V1 and V2 endpoints. The sample payload from Azure AD shows the accessToken which if were correct would resolve this issue.

Hmm, it seems I've been hunting ghosts for the past few hours..

[edward-cross]

Just to add to the voices requesting this feature. As others have pointed out, Azure Web Apps show the access token within the token store via the /.auth/me endpoint. I can't see how this is any more of a security concern than with Static Web Apps.

I also require the ability to customise the requested scopes for the token, as we can with Azure Web Apps via adjusting the "loginParameters" option within Azure Resource Editor. It seems this is possible to do within the staticwebapp.config.json file, as per the Graph API example for Static Web Apps, but without sight of the access token it's hard to tell if the "loginParameters" option is being used during the token request process.

[ltwlf]

I share your frustration. Encountering this issue with bring in your own function is even more problematic, as the X-MS-* tokens differ when calling the function through the static web app or from an external client. This design oversight hinders consistent behavior and token usage. It appears that SWA is only suitable for straightforward cases that don't require access to Graph/OAuth resources, which is quite disappointing.

[jassent]

I share your frustration. Encountering this issue with bring in your own function is even more problematic, as the X-MS-* tokens differ when calling the function through the static web app or from an external client. This design oversight hinders consistent behavior and token usage. It appears that SWA is only suitable for straightforward cases that don't require access to Graph/OAuth resources, which is quite disappointing.

I am using SWA secured by Azure AD with Graph in two published applications. Takes an extra step to get a token. Below is some code. Please note, this for an Azure Function API, not the front-end Client. Secrets should not be stored or accessed in the Client.

var clientprincipal = req.ParsePrincipal();

var TenantId = Environment.GetEnvironmentVariable("TenantId");
var ClientId = Environment.GetEnvironmentVariable("ClientId");
var ClientSecret = Environment.GetEnvironmentVariable("ClientSecret");

var authenticationProvider = new BaseBearerTokenAuthenticationProvider(new TokenProvider() { TenantId = TenantId, ClientId = ClientId, ClientSecret = ClientSecret });

var client = new GraphServiceClient(authenticationProvider);

Microsoft.Graph.Models.User? user = await client.Users[clientprincipal.UserDetails].GetAsync().ConfigureAwait(false);

The Function App is given access to the Graph API. The function then reads the ClientPrincipal from the request header and calls Graph using the upn(e-mail address) which is the UserDetails from the ClientPrincipal. You could also use the Azure Id in the same way in the Graph client.

The ParsePrincipal is borrowed from somewhere on the Internet - maybe even the Microsoft.com website for SWA Bring Your Own Functions docs:

public static ClientPrincipal ParsePrincipal(this HttpRequestData req)
        {
            //ClaimsPrincipal
            var principal = new ClientPrincipal();

            if (req.Headers.TryGetValues("x-ms-client-principal", out var header))
            {
                var data = header.First();
                var decoded = Convert.FromBase64String(data);
                var json = Encoding.UTF8.GetString(decoded);
                principal = JsonSerializer.Deserialize<ClientPrincipal>(json, new JsonSerializerOptions { PropertyNameCaseInsensitive = true })!;
            }
            principal.UserRoles = principal.UserRoles?.Except(new[] { "anonymous" }, StringComparer.CurrentCultureIgnoreCase);

            if (!principal.UserRoles?.Any() ?? true)
            {
                return null;
            }

            return principal;

        }

[ltwlf]

Thanks for sharing. This uses client credential flow. From security perspective this only necessary for special cases e.g. background services. Changing security settings because of flaws in the architecture of swa is not an option for me.

[jassent]

Thanks for sharing. This uses client credential flow. From security perspective this only necessary for special cases e.g. background services. Changing security settings because of flaws in the architecture of swa is not an option for me.

Good point. I went back and edited my comment to clarify that the code was being run in an Azure Function API and not on the front-end client. I don't think there are any problems using client credential flow or secrets within an API and wouldn't call that a special case. But I also don't want to divert from the original issue that having the Access Token would make it efficient to access Graph directly in the Client.

[shobhitkasliwal-onbe]

Any update on how can I retrieve the Access token or id_token from frontend react code?

[manoj271106]

I am trying to do the same thing as above , any update on this?

[ARamadan123]

Same here, this feature is really needed as I need access token to call protected resources. Any suggestions for integrating this feature with React code would be highly appreciated.

[JefGreen]

Same here! In order to work around this issue, we ended up using Azure Web Apps with a single container instead. If you decide to go down this route, please note that after each deployment /.auth/me can return an empty object until the user authenticate again. Since the token is still valid, we are using the local storage to palliate to this other issue. It was a painful journey to get there so I hope this can help someone.

[lancerael-undo]

Can we get more details on why you would like the access token to be exposed? We have intentionally hidden in from the /.auth/me output for security reasons but can consider exposing it there if there is sufficient reason to expose it.

Just adding a "me too" to this thread. We have used /.auth/me to log in which is great, but unfortunately we need an access token to authorise the specific user on our APIs. At the moment we have to layer MSAL on top to get the token which creates a popup. It's mostly ok for the user but it's convoluted and gives us issues in e2e testing.

This issue has been open for nearly a year and a half. At least 24 people are discussing the need for it from then until now. @mkarmark does this yet meet the threshold for exposing this as you described?

[kevinsschmidt]

+1

[thomasgauvin]

Hi folks, thanks everyone for sharing your use cases. Here's the status on where we are regarding access tokens:

We hear the need, and we're working to put down the infrastructure improvements to get this, but we are still many months away. After investigations, the work required to enable this turned out to be more than a 'config change' as previously alluded to; we have to make significant infrastructural changes to support providing access tokens. Given Static Web Apps' distributed & multi-tenant nature, we do not currently have the ability to provide token stores as other products in the App Service do https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization and this is blocking us from enabling this on SWA resources.

At this time, my recommendation would be to opt for App Service or Functions for your application hosting if those options meet your requirements. While we are aware of this limitation for SWA and are working on it, there's no timeline that I can share at this time.

For readers of the thread, if you are also running into this blocker, please 👍 the issue and add a comment with your use case and the impact this has on your workflow.

[collinstevens]

@thomasgauvin can you explain what the changes may be bringing in the future?

I would like to deploy to Azure Static Web Apps, but I cannot because of this issue.

The API I would have behind my Azure Static Web App is used by multiple other consumers and authentication/authorization methods; therefore I require the access token from a typical authorization code with PKCE flow to Microsoft Entra.

Without this capability, I'm integrating and managing MSAL myself.

[mvrius]

+1 on this feature request.

I use On-Behalf-Of flows between backend and next tier services.

This feature gap doesn't allow migration over to Static Web Apps since we have no token to use for On-Behalf-Of MSAL flows.

The workaround to add another layer for SWA MSAL auth is ok, but with additional login redirects - so it's not production suitable.

[nitelite]

+1 on this feature request.

Similarly to what others have mentioned, we wanted to start using SWA instead of App Services for your static web apps. Unforunately we also need access to the access token or id token for the user, so we can pass this to along to our backend services to validate access there.

We turned on authentication in our SWA config file and was very happy to see that it was an incredibly smooth experience to make sure users are authenticated on the frontend, only to realize it doesn't actually help us, since we have no way of passing the authentication onto the backend service when requesting data.

It would be very useful if the token was available either through a seperate Microsoft Entra ID auth provider endpoint (/.auth/aad/token?) or possibly provided as part of the /.auth/me response, as long as the auth provider used has tokens it provides.

[jassent]

+1 on this feature request.

Similarly to what others have mentioned, we wanted to start using SWA instead of App Services for your static web apps. Unforunately we also need access to the access token or id token for the user, so we can pass this to along to our backend services to validate access there.

We turned on authentication in our SWA config file and was very happy to see that it was an incredibly smooth experience to make sure users are authenticated on the frontend, only to realize it doesn't actually help us, since we have no way of passing the authentication onto the backend service when requesting data.

It would be very useful if the token was available either through a seperate Microsoft Entra ID auth provider endpoint (/.auth/aad/token?) or possibly provided as part of the /.auth/me response, as long as the auth provider used has tokens it provides.

This was a very good explanation of the situation and the desired outcome.

[mvrius]

I would be happy if the tokens were made available in headers only, similar to App Service

https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-user-identities

Provider tokens are also exposed through similar headers. For example, the Microsoft Identity Provider also sets X-MS-TOKEN-AAD-ACCESS-TOKEN and X-MS-TOKEN-AAD-ID-TOKEN as appropriate.

[amithkk]

Adding another +1 to this issue. It's very beneficial for us to be able to split out the app service and static web app to ensure that we don't have to restart the app service for minor UI changes.

Without this feature, we are forced to either roll our own MSAL auth or bundle the front and back end into an app service. Neither option is appealing given that SWAs primary purpose is to make deploying, managing and securing frontends easy

[jason-johnson]

Hi folks, thanks everyone for sharing your use cases. Here's the status on where we are regarding access tokens:

We hear the need, and we're working to put down the infrastructure improvements to get this, but we are still many months away. After investigations, the work required to enable this turned out to be more than a 'config change' as previously alluded to; we have to make significant infrastructural changes to support providing access tokens. Given Static Web Apps' distributed & multi-tenant nature, we do not currently have the ability to provide token stores as other products in the App Service do https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization and this is blocking us from enabling this on SWA resources.

Hi @thomasgauvin and thanks for the response. But if this is the case, how does the GetRoles mechanism work? There seems to be a way to call the Graph API from SWA, we just don't have access to it beyond the GetRoles mechanism (assuming this is working?). Would it be easier to simply expose this a bit more so SWAs can at least have access to the graph API?

[seidnerj]

Why not just setup yourself as a custom oauth provider with your own end points that behind the scene pass everything back and forth to the original oauth endpoints?

That way you could get the authorization code in the callback and then set a cookie with that value before passing it to SWA. Eventually SWA will call your token endpoint with that same auth code, you can then capture the access token and save it mapped to the auth code. Then, in the first request that the user does to your own endpoint (e.g. api), the auth code will be sent since its stored in the cookie, server side you will then translate this to the access token and set the access token as the cookie’s value.

From this point on, every call to your endpoint will send the access token as well, which you can then use server side to verify that the user is in fact logged in along with any other checks by using that access token against the idp’s user info endpoint.

[seidnerj]

Why not just setup yourself as a custom oauth provider with your own end points that behind the scene pass everything back and forth to the original oauth endpoints?

That way you could get the authorization code in the callback and then set a cookie with that value before passing it to SWA. Eventually SWA will call your token endpoint with that same auth code, you can then capture the access token and save it mapped to the auth code. Then, in the first request that the user does to your own endpoint (e.g. api), the auth code will be sent since its stored in the cookie, server side you will then translate this to the access token and set the access token as the cookie’s value.

From this point on, every call to your endpoint will send the access token as well, which you can then use server side to verify that the user is in fact logged in along with any other checks by using that access token against the idp’s user info endpoint.

I've successfully implemented this method and was able to store the access token in a cookie which I can now use to verify the user's identity.

[OscarLijoBusto]

+1

[afreidz]

+1 I want to secure my azure functions for a SWA without having to roll my own authentication mechanism. Being able to get the token used by the front-end login to pass to the /api/* functions for decoding/verification is the desired outcome for me.

[Moffmo]

Would it be possible to add something like an aquire token endpoint on the built in APIS e.g. /auth/.me/aquiretoken/{{resource}} The implementation would basically be a on behalf of token flow using the original token that /auth/.me has access to but is not exposing?

I'm surprised this didn't get raised in preview testing - almost every SPA needs to call APIs with auth tokens?

[seidnerj]

How is this not solved yet?! I had to go through multiple hoops to implement a workaround which I'm not at all pleased with. Thinking about moving on from static web apps altogether.

[matthew77777]

Hello @afreidz

I saw your comment bellow and I was taking the same approach with you.

+1 I want to secure my azure functions for a SWA without having to roll my own authentication mechanism. Being able to get the token used by the front-end login to pass to the /api/* functions for decoding/verification is the desired outcome for me.

I successfully decoded authorization header and x-ms-auth-token , However, I couldn't find a way to verify these tokens send from SWA to App function and I would like to know which jwks or jwks_url can verify these tokens?

Could you please let me know if you already find one ?

Thank you so much.

[afreidz]

Hey @matthew77777,

I also realized that, while I could decode the token, I couldn’t verify it. So I ended up noticing that the app framework I was using (Astro) had an integration with auth.js, which has an azure ad integration as well. It was VERY trivial to implement that and handle auth outside of azure static web. However, with that in place, coupled with my app framework having a similar method for api routes that eliminated the need for azure functions, I questioned what azure static web would provide outside of hosting. This issue led me to abandon azure static web. I still use Active Directory and Postgres thru azure, but I’m gonna host on vercel (serverless) as it has better integrations with Astro.

This is a bummer because this product should start to compete with vercel/netlify and even Astro itself, for Microsoft. But it’s got a lot of “table stakes” feature to work on!

Hope this helps!

[seidnerj]

Hey @matthew77777,

I also realized that, while I could decode the token, I couldn’t verify it. So I ended up noticing that the app framework I was using (Astro) had an integration with auth.js, which has an azure ad integration as well. It was VERY trivial to implement that and handle auth outside of azure static web. However, with that in place, coupled with my app framework having a similar method for api routes that eliminated the need for azure functions, I questioned what azure static web would provide outside of hosting. This issue led me to abandon azure static web. I still use Active Directory and Postgres thru azure, but I’m gonna host on vercel (serverless) as it has better integrations with Astro.

This is a bummer because this product should start to compete with vercel/netlify and even Astro itself, for Microsoft. But it’s got a lot of “table stakes” feature to work on!

Hope this helps!

Yes - SWA is a crippled service. For anything beyond a personal project it's pretty useless. I wish I'd had known that before I started using it.

I did find workarounds for everything but they came at a high cost whereas in other platforms it would have been built-in.

I am planning to migrate out soon and won't be coming back.