At some point recently, Microsoft started including IdentityServer functionality in the ASP.NET Core react template (on top of Identity Core). I'm trying to clearly understand the implications of this difference. As such, I've started with the template, attached here:
https://drive.google.com/file/d/1GV4UNhsPp_PdPk2RKjoz0490Vn9A6geY/view?usp=sharing
and done a few things:
-Scaffolded all of the identity assets
-Commented out form startup.cs the following lines:
(in ConfigureServices)
//services.AddIdentityServer()
// .AddApiAuthorization<ApplicationUser, ApplicationDbContext>();
services.AddAuthentication();
//.AddIdentityServerJwt();
(in Configure)
//app.UseIdentityServer();
On the client, I stubbed out a bit of code, and also made this change in FetchData.js:
async populateWeatherData() {
//const token = await authService.getAccessToken();
const response = await fetch('weatherforecast', {
//headers: !token ? {} : { 'Authorization': `Bearer ${token}` },
credentials: 'same-origin',
});
const data = await response.json();
this.setState({ forecasts: data, loading: false });
}
}
My understanding here is that after we log in, we'll have a cookie with our login info, and using credentials: 'same-origin' causes this to be sent to the API endpoint which is secured.
This works and seems secure to me. To test:
-Start the project -Navigate to /identity/account/login (this won't happen automatically because of other client code I stubbed out) -Create an account for yourself. (you'll have to apply database migrations when prompted.) Then login with that account.
Now, you can click on "Fetch data" and the data will load. To confirm that this is actually secure, above where it says
credentials: 'same-origin',
replace the value with 'omit'. Then repeat the process. Manually navigate to the login page and click on "fetch data." It will fail.
Based on this, I'd like confirmation that in the ASP.NET Core React project template, I'm able to achieve the same API endpoint security without leveraging IdentityServer. Is this correct?
If so, what is the value added by leveraging IdentityServer? My hypothesis is that everything works well in this template because we're authenticating through a web form and storing the token in a cookie, but that IdentityServer gives us flexibility for additional scenarios (that we're not really leveraging in this template).
To complicate things a bit further, in this post comparing ASP.NET Identity Core with Identity Server,
.NET Core Identity vs IdentityServer4
The answer states: "ASP.NET Core Identity is a membership system and it does not provide any ready to use endpoints and neither token management or support for different ways how to authorize."
But based on what I'm showing here, it seems that ASP.NET Core Identity does indeed provide a mechanism for authorization, and I believe token management since it's returning to me a token that I'll store in a cookie and pass back when I want to hit an endpoint.
To summarize my questions again:
-Is my modified sample as secure without Identity Server, as it was with it?
-If yes, what's the added value of leveraging Identity Server in the context of this template?
-Also if yes, is it accurate that there's some overlap between the two?
Thanks...
I came across this section in their documentation which describes in detail the differences between the available options to authenticate within ASP.NET Core.
I felt better after reading through it and confirmed the feeling I think we both have. We don't need IdentityServer4 to correctly secure our API.
I struggled with the same questions and as you, I feel like I don't know what is the added value of having IdentityServer4 for a simple SPA.
UPDATE:
Microsoft will be removing the dependency to IdentityServer in .NET 8.
https://devblogs.microsoft.com/dotnet/improvements-auth-identity-aspnetcore-8/