Search code examples
asp.netasp.net-coreidentityserver4

Duende Identity Server Internal API Authorization


I am using IdentityServer 7 with Asp.Net Identity in the same application.

How can I possibly keep the RazorPages and "cookies" authenitication handler that is registered with the Duende Identity Service Helper but allow for my User Management system to have a different redirect i.e. just say unauthorized not redirect to login page.

Is this related to AddAuthentication Challenge logic?

Will having an Authorized api in the same application as the IdentityServer itself create a conflict?

The only API in this project is for user with registerUser, updatePhone, confirnPhone, getUserById etc

And besides registerUser all require the [Authorize] Attribute

services.AddAuthentication()
    .AddGoogle("google", options =>{...});

Does this mean I need to split User Management and treat it like a resource with IdentityServer linking to the same database?

Or can I still keep this in the same application for simplicity with some workaround?


Solution

  • 1)The behavior you descried regarding redirecting unauthorized users to a login page is expected of web applications that use cookie-based authentication. In your case, since you're integrating IdentityServer, you have additional flexibility to control how unauthorized requests are handled.To customize the redirect behavior for unauthorized requests in certain parts of your application like your User Management system, you can use the OnRedirectToLogin event in the cookie authentication options.

    example below is the code will give 401 to the unauthoried user:

    services.AddAuthentication(options =>
    {
        // Your existing authentication setup
    })
    .AddCookie(options =>
    {
        options.Events.OnRedirectToLogin = context =>
        {
            if (context.Request.Path.StartsWithSegments("/api") && context.Response.StatusCode == 200)
            {
                context.Response.StatusCode = 401;
                return Task.CompletedTask;
            }
    
            context.Response.Redirect(context.RedirectUri);
            return Task.CompletedTask;
        };
    });
    

    2)Will having an Authorized api in the same application as the IdentityServer itself create a conflict?

    No, Using the [Authorize] attribute with APIs in the same application as IdentityServer should not inherently cause conflicts. but still you have to configure authentication schemes properly. To avoid conflicts, make sure your API endpoints are correctly protected using the [Authorize] attribute and that the authentication scheme they rely on is correctly set up to handle API requests, possibly using bearer tokens.

    3)Does this mean I need to split User Management and treat it like a resource with IdentityServer linking to the same database?

    Or can I still keep this in the same application for simplicity with some workaround?

    It's entirely feasible to keep your user management system within the same application as IdentityServer, especially for simpler or moderately complex scenarios. This can simplify deployment and maintenance while still offering a good level of security and functionality.

    However, as your application grows in complexity or if you need to scale parts of your system differently, you might consider separating concerns by moving the user management system into a separate API. This API would still use IdentityServer for authentication but would be decoupled from the IdentityServer application itself. This approach offers greater flexibility and can help keep your systems organized and scalable.

    You do not necessarily need to split your user management system into a separate application or treat it as an external resource. With the right configurations such as customizing the unauthorized redirect behavior and carefully configuring authentication schemes you can maintain simplicity and coherence in your application while leveraging the full power of IdentityServer and ASP.NET Identity together.Ensure your configurations are precise and tailored to your application's needs, especially around authentication and authorization.