I would like to write a SPA application in React that will communicate with the .net core API.
I think it would be easier to have two separate projects (API + UI) on different domains.
API should be protected, that only authenticated users could make requests.
In react i'd like to have login and registration forms that will allow me to register and login users, and also I would like to have social providers. I would like to create whole UI for managing users in react SPA, and saving this data using API.
I did a lot of research, and I'm a little confused.
I would really like to use Core Identity because it simply looks like made for it
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-5.0
it has a ready to go model of Users, Claims, Roles etc.
it has built in services for managing passwords, users, roles etc
it has features to customize authentication schemes, policies, roles etc,
there are lot of reasons why i think this is a good solution.
Unfortunatelly, on the documentation site there is an information that for SPA integration it works combined with Identity Server.
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization?view=aspnetcore-5.0
Last year I went throug every episode of this tutorial https://www.youtube.com/watch?v=Fhfvbl_KbWo&ab_channel=RawCodingRawCoding (btw. great tutorial), and I'm pretty sure, that I don't want to use Identity Server 4 for this scenario. As far as I know - this is the best solution when you want to have SSO for multiple applications, and you would like to provide one common way to authenticate user for all of it. And it has it's own UI for managing user registration, login and managing. This is not what I need - I just want to have it all written in React, cause I want all application to have the same mui theme without redirects to Identity Server.
But maybe I'm wrong, and Identity Server will work for me. But I found it to be quite lot of work to provide my own UI rather than MVC
(https://medium.com/#piotrkarpaa/using-spa-react-angular-ui-with-identity-server-4-dc1f57e90b2c)
For now I think, that I should use Identity Core on the backend, and communicate with it from React SPA with custom controllers like in here:
https://www.c-sharpcorner.com/article/authentication-and-authorization-in-asp-net-core-web-api-with-json-web-tokens/
Authenticating React SPA with API with JWT token - I think that this will work according to this example:
https://www.youtube.com/watch?v=FSUa8Vd-td0&ab_channel=Geek%27sLesson - but in here this is without Identity Core.
But I'm not sure that this is the best approach, and I don't know if I will be able to add Social Providers this way.
Also, I found serveral tutorials how to comine React App with .net core backend (and authentication) like this one:
https://www.red-gate.com/simple-talk/development/dotnet-development/integrate-create-react-app-with-net-core-5/
but I would like to have two separate applications, API and UI.
What is the best approach to achieve this goal?
EDIT:
Few months later, I already have SPA application, API and IS4. There is lot of problems to make Identity Server views (registration, login etc) look similar to SPA Application. (React app in MUI, MVC with bootstrap... ).
Now I think it was a bad decision, causing lot of problems:
2 way integration of users from API and Identity Server 4
changes in SPA layout, styles, colors - it all needs to be maintened on Identity Server 4 too
Bad user expirience - editing user profile on another application, on another domain with slightly different styles
Now I'm about to rewrite application, not to use Identity Server 4. Components for registration, login and editing user profile will be in SPA application, maintaining users will be done using API.
The only think I do not know is how can I use social providers with this aproach?
My question is still remaining without answer, can someone help me with providing proper solution?
Finally I found proper solution for me:
https://mahdikarimipour.com/blog/google-auth-for-react-with-aspnet-identity
thank you for your post: Mahdi Karimipour
Related
I could really use some help. I'm newer to C# and ASP.Net MVC 5. I currently have an internal website that I've build that will run on IIS. The final component I need to work out is authorization. This has been surprisingly hard to find. The biggest issue I have found is that Microsoft has changed the way to handle this multiple times. It appears to me that membership, universal membership, and simple membership are no longer used and the way to do things now is with Identity. As I didn't know what I was looking for at first I looked into all of these at least some as I was under the impression that identity was a .Net Core thing. All of the blog posts and tutorials seems to deal with outside web sites that the user would log into. That isn't what I need. Also, most of the answers are really old, so I'm not sure if this is the modern way of doing things.
My shop currently uses ASP.NET MVC 5 (not core) and we have on premise active directory (AD). What I want to accomplish is to have all AD users have access to the site. Then have a page where I can grant select users admin privileges so they can manage their staff. I'm currently using a code first approach with Entity framework, which I'm also new to. I had planned to use the [Authorize] attribute to accomplish this, but again, I'm a bit lost in what I need to do to hook this all up.
So my questions is: Using code first with Entity Framework, how can I use AD for my authentication and Identity for my authorization when my site will run on IIS? Also, should I be using Identity?
My roles will be pretty simple. Probably Admin and Manager. Admin will have access over everything, Manager will have access over there section.
Any help is greatly appreciated. Thank you.
I'm working on building a series of micro-services using Aspnet Core. A mobile application, desktop application and web-application will consume the services over Http REST APIs.
For user auth, I'm utilizing the Aspnet Core Identity platform, but I'm exposing the creation of user accounts via a REST API. The clients make a REST call with the credential information and my API uses the Microsoft Identity APIs to provision the user. The user would be authorized to hit the individual resource servers with an auth server using IdentityServer4.
I have two questions that I've not been able to find clear guidance on from a security stand-point. Should the Aspnet Core project that utilizes Microsoft Identity for user creation be in an independent Aspnet Core project from the project that handles auth via IdentityServer4? Are there downsides do separating the two out that I need to consider?
The Microsoft Identity API has template and Razor Views that can be used to handle the auth from a server-side perspective, including redirects on account creation or sign-in etc. If I'm doing everything via SPA or Client-side native apps, is there anything wrong with just providing a POST API that accepts the user information, creates the account via UserManager<T> and returns the UserId?
I want to provide a dedicated sign-in page, similar to FB/Google/Twitter etc for Auth to happen across any app that wants to authorize a user for my services. I don't typically see account creation as part of the OAuth process though. Is it typical that you would allow for redirects to an account creation page, that redirects back to a client upon successful account creation or is that process typically just used for Auth via OAuth flows?
I would suggest to consider using one service for IDS4 and ASP.NET Identity since they can be integrated and give you the full functionality you're looking for(auth, and users management).
IDS4 has examples and good documentations regarding that.
To me, I think separating them would be an over engineering.
one example: when IDS4 generate access token for a user, you should get claims, roles and validate username and password, all of that are stored in ASP.NET Identity.
So for more details you can check the docs of Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html
or it's my pleasure to check my little blog post that I tried to give some more detailed and step by step.
https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/
Start with IDS4 link because it might be enough :)
The main point when thinking about security management UI is how to secure that UI. And the most safe approach for today is cookie-based auth with same-site cookie (the way, MVC uses by default). Consider that when and if selecting serverless SPA pattern. For management purposes-app having strict backend is much more secure than token-based access to distributed api-s.
Regarding the application hosting, #VidmantasBlazevicius is absolutely right, there is no the only strategy: hosting all the services in one app is simpler, so it better fit lo to middle loaded systems. But with raise of the number of users and authentication requests, you might want to scale, and separating management UI from authentication is one of the ways to handle that.
I have an Asp.Net Web form based Application, which relies on an Identity Server for authentication. I'm planning to create a Chat to be used as an independent Asp.Net Core Web Application (using SignalR), which would be authenticated in the same way as the Asp.Net Web form based Application (Both using the "Single Sign-On" approach). So, based on the given context, the key point is that I'd like to be able to render the Chat from inside the Web forms application through an IFRAME and I'm wondering if anyone could help me to identify potential problems that I could come across if I use this approach, specially when it comes to the Security stuff.
Thanks in advance.
Iframes act like a normal pages, or tabs in most aspects.
SSO protocols, including OIDC, are designed exactly to securely simplify the authentication procedure for different web (but not only) apps.
Follow the recommendations regarding the choice of grant type, always use https, do not store refresh tokens nor secrets in browser, and you are secure.
Enable two factor auth, signing keys rotation, and you are secure a bit more. There is nothing absolute in the world, but for general purposees... you are on the right way.
I'm building several App's or Modules (Each got its own Project or might be a solution) and I need to develop a central core module that acts as a configuration App as well as the main login portal and users management (Using the built-in Identity 2.0)
I need a hint or a road map on how I can allow that functionality so when a user requests a specific module (Might be on a completely another URL, Database or Machine), he'll be redirected to the login page and then return back to the requested url. Of course I need to not include the same login mechanics and controllers in each and every project.
PS: I still need to use the normal Identity User Role check in the Applications/Modules like usual.
I decided to go with IdentityServer4
There is a learning curve here but I decided to go ahead as it will be a better solution in the future.
I am hoping someone can clear up how these things can work together.
I want to be my own identity provider, so in my web api I have an OAuth token provider. I want users to register with me and then be authenticated using my token provider. The idea in the future is that more of my mobile apps and web apps will be accessible using the OAuth login sharing the user's identity.
So, if I use azure mobile services how do I implement the normal asp.net identity stuff?
And, how would a normal web app be able to use the data stored in azure mobile services? Would I have two dbcontexts one for mobile and one for web?
I've been reading and watching a lot of stuff on azure but nothing seems to show how I can do this. Most of it has to do with using external providers like facebook, ms, twitter, etc. I want to be one of those external providers, just not sure how to do it and allow my websites to still use the .net identity data.
If you could point me to or post some example / tutorial / blogs that would be great.
This is a supported scenario, although it isn't documented very well at the moment.
The Mobile Services .NET runtime is built on the ASP.NET Katana authentication middleware. The mobile service abstracts these middleware using the LoginProvider base class. The authentication model was recently made extensible for situations such as yours. In order to have Mobile Services recognize and use your identity provider, you would have to create your own LoginProvider.
There are currently two examples of this:
Adding a Katana middleware as an identity provider - part of this post.
Creating a custom username/password setup - tutorial here.
You could certainly use these techniques to wrap the standard ASP.NET identity functionality.
As to your question about accessing the data, there are a variety of approaches. Your web app could treat Mobile Services as a backend and pass through requests. This is basically treating the web app as an additional client platform, peer to your mobile apps. Another option is to, as you said, create multiple DBContexts. While you might get slightly better performance, this comes with a code maintainability tradeoff. It also wouldn't scale well if you build multiple web apps on the same data backend.