ASP.NET Core Identity Project Frontend vs API Backend RRS feed

  • Question

  • User1768357016 posted

    I am building a asp.net core application.  I have a backend API (asp.net core mvc api) that separates data / database connections and standard objects (standard.net) and a web frontend project that uses asp.net core mvc with identity.  I've seen examples that separates the identity user auth on the frontend and uses certs and other methods for securing the backend.  My goal is to keep them isolated for security, however if I use identity on the frontend it will require access to a database which seems to negate my desire to keep the database connection isolated to the API.  I'm wondering how others handle this...do you just setup a 2nd DB that holds identity information, implement identity on the API and expose it on the UI (would be different than the examples I've seen) or something else?

    My solution is hosted in Azure if that helps.  I plan on having an app in the future that would also require authentication and leverage the API.  I'm also using .NET 5.

    Would love to hear everyone's thoughts on the architecture.  I've seen multiple strategies but don't seem to be anything pointing to one being better than the others.  My hope/thought is to keep my API available to multiple clients but isolated to specific functions through separate controllers and DB connection further isolated to API.

    Saturday, February 13, 2021 3:55 AM

All replies

  • User1120430333 posted

    It can be done be the example shown in the link, which is for a JavaScript  front-end. I think the key for you would be a Service Layer using HTTPClient that did all CRUD operations in the client-side code with the WebAPI and using the DTO pattern of DTO(s) known by the WebAPI client-side and WebAPI service-side code.

    I would let the Identity database be created using LocalDB on the client-side upon the initial registration of a user, and then I would move the Identity.MDF to MS SQL Server Data directory and attach the MDF file to the database engine.  

    ASP.NET Identity 2.1 with ASP.NET Web API 2.2 (Accounts Management) - Part 1 - Bit of Technology

    I would send DTO(s) between the client and the service for CRUD with the database using EF. I would implement SoC throughout the client-side and service-side code. You can have model in the DAL one for the Identity database. 

    I am using Domain Model objects DM(s) and ViewModel objects VM(s) on the client-side code, keeping the controllers thin. I keep the controllers thin in the WebAPI too by implementing a DAL using the DAO pattern.

    Data transfer object - Wikipedia

    Create Data Transfer Objects (DTOs) | Microsoft Docs

    Data Transfer Object Design Pattern in C# - CodeProject

    Kinds of Models | DevIQ

    Separation of concerns - Wikipedia

    Architectural principles | Microsoft Docs

    Data Access Object (DAO) design pattern in Java - Tutorial Example (javarevisited.blogspot.com)

    But I think the best result for you concerning the WebAPI is to have a WebAPI dedicated to Identity database. You would have another WebAPI dedicated to the business database.

    I have a solution that shows the overall project structure of the ASP.NET Core MVC client project consuming a ASP.NET Core WebAPI doing CRUD with the database using EF and the concepts that I have shown.

    darnold924/PublishingCompany (github.com)

    I think you can easily implement Identity database on the backend behind the WebAPI if you implement well known design patterns and architectural principles.


    Saturday, February 13, 2021 9:41 AM
  • User-474980206 posted

    The front end can call the backend to access the identity database. You use a custom storage provider


    as you are in azure, you could also just use azure ad.

    Saturday, February 13, 2021 4:33 PM
  • User1768357016 posted

    I think this does a good job at answering my question.  I am using DTOs already and mostly have the separation and patterns your example shows.  You break a few items out that I didn't but might consider.

    I agree that creating a 2nd identity API and keeping separate appears to be the best approach.  I haven't dived into mobile app just yet so will look at that a bit more.  I'd like to keep this open to see other opinions if any.  I would think the mobile app could take advantage of the same identity API?

    Would you secure the API connections through cert and keys and pass identity user information for application API access then?  I don't see many examples doing this so would love to see examples that fully implement this.

    Thank you!

    Saturday, February 13, 2021 6:53 PM
  • User1120430333 posted


    Myself, I would use SSL for the Identity WebApi.

    WebApi purpose is to work  with different clients using Rest. So mobile  clients should have no problems.

    Saturday, February 13, 2021 10:18 PM
  • User-474980206 posted

    mobile apps would typically use oauth and bearer tokens as its so hard to deal with cookies from code (especially if a webview is involved). there are several oauth sdks for mobile. 

    Sunday, February 14, 2021 12:58 AM
  • User1768357016 posted


    Do you know of any examples that integrate with a backend asp.net core identity storage for user data to auth with mobile app?  I found some examples that are 6 plus years old but not very helpful.  I suppose you can configure such that the backend identity system uses oauth / bearer tokens?

    I've looked at IdentityServer4 which even MS points to but looks like open source support ended and not sure I need something as complicated as this.

    Thank you!

    Monday, February 15, 2021 3:40 AM