Last post Feb 15, 2021 03:40 AM by KLHCODER
Feb 13, 2021 03:55 AM|KLHCODER|LINK
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.
Feb 13, 2021 09:41 AM|DA924|LINK
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.
I think you can easily implement Identity database on the backend behind the WebAPI if you implement well known design patterns and architectural principles.
Feb 13, 2021 04:33 PM|bruce (sqlwork.com)|LINK
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.
Feb 13, 2021 06:53 PM|KLHCODER|LINK
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.
Feb 13, 2021 10:18 PM|DA924|LINK
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.
Feb 14, 2021 12:58 AM|bruce (sqlwork.com)|LINK
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.
Feb 15, 2021 03:40 AM|KLHCODER|LINK
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.