IdentityServer4 VS microsoft-authentication-library-for-js

Found this 6 year old issue https://github.com/IdentityServer/IdentityServer4/issues/736 but I didn't quite get the solution and it sounded awfully complicated.

IdentityServer4 can provide a base infrastructure or serve as reference code if you're trying to create your own tokens for your own users.

Read up on IdentityServer, they also have good starter templates. Scott Brady has the best tutorials IMHO.

The old v4 of IdentityServer was free under the Apache license (https://github.com/IdentityServer/IdentityServer4), but newer versions went all commercial.

Here's a link to IdentityServer's Github repository, [check the samples folder](https://github.com/IdentityServer/IdentityServer4) for the different types of scenarios and code that is used, and you're off to the races.

If you want federated login, use OpenID Connect with ASP.NET Identity combined with IdentityServer4.

Please be aware that End of Support for Identity Server is in a few weeks, if you mean https://github.com/IdentityServer/IdentityServer4

You can use the sample provided at https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples and integrate it in hooks.server.ts.

I'm utilizing the Authorization Code sample provided in the MSAL Node.js library (https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples/auth-code), with the only modification being the addition of the aforementioned scope to my configuration. Below, I've shared the relevant segment of my customConfig.json and the primary code snippet where the error surfaces.

As the backend handles the token acquisition, no other code or library, such as MSAL.js, is required in the single-page application itself. This also means that no tokens are required to be stored in the browser session or local storage. By encrypting and storing the access token in an HttpOnly cookie protects it from XSS attacks, and scoping it to the API domain and setting SameSite=strict ensures that the cookie is automatically sent with all proxied API first-party requests. More on SameSite cookies can be read here.

The easiest way to secure Angular apps with the Microsoft Identity Platform is by using the MSAL (Microsoft Authentication Library) Angular package. This package contains Angular-specific building blocks for implementing MSAL in your app.

For example: https://github.com/AzureAD/microsoft-authentication-library-for-js

I was imagining something like this, and since you’ve got it on the frontend already just throwing the token to the backend and letting it validate the token https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/node-token-validation-samples/basic-sample

I did an azure ad implementation recently(laravel / SPA). I used the offical msal.js library (https://github.com/AzureAD/microsoft-authentication-library-for-js) to present the azure ad login screen. After successful login, I take the received azure ad access token and send it to my laravel based api. there, I verify the token and if valid and the user exists in the app, I create an access token for my apis and return it to the spa. The spa then uses this token for further requests, until the lifetime of the token expires. Hope that helps a bit, feel free to ask for details :)