6

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...

BenjiFB
  • 4,545
  • 10
  • 46
  • 53
  • Did you try putting a breakpoint in your API controller to check it was authenticated? (`this.User`). if it was authenticated, did it have the expected claims? AFAIK, it isn't recommended to use Cookies for authenticated API calls - because Cookies are for sessions not for authentication tokens. But I would be interested to know what your findings were from this. – oatsoda Oct 20 '20 at 13:26

0 Answers0