We have an IdentityServer4 project, A web Api project (.net core 5) and an SPA front project (Vue.js).
User creation will be done when SPA send a register request to IS4 project local endpoint.
Then we have a createCompany endpoint which need to create a a company in webApi project and update CompanyId in IdentityServer4 project.
The question is how it is better to be implemented ?
Should webApi directly call IdentityServer4 endpoint to update companyId or front end should send seperate request to IS4 for update companyId ?
What is the best way to access UserManager from webApi ? for example get the list of users with specific CompanyId ? Or specific EmailAddress ? Should I create a separate local endpoint for each one of them in IS4 ? Is there any way to fully manage users from webapi directly without creating many endpoints for user management in Identityserver4 ?
I think you're missing some info on how IdentityServer4, OAuth 2.0, and OpenID Connect works. IdentityServer4 is an OAuth and OpenID Connect implementation. IdentityServer4 does not have any way to manage a user database or authenticate users. It is for generating OAuth 2 and OpenID Connect compliant tokens using a user store of your choice behind it.
Some options for managing users includes:
ASP.NET Core Identity
Your own homegrown solution
Services such as Okta, Auth0, Azure AD B2C, etc.
Don't handle users at all in the traditional sense, and use OpenID Connect with Google Authentication, Facebook Authentication, etc. (this is where you see on websites "Log in with Google" and things like that).
Read a little more here at the updated IdentityServer4 project, Duende IdentityServer.
You'll need to use one of these to manage users and I'd recommend not tying a ton of custom logic to IdentityServer4 specifically unless you really need to. Keep it for authorization and leave everything else to your own API or one of these other solutions mentioned.
Keep in mind, IdentityServer4 is almost end of life and will not be updated after November 2022 and is only receiving critical security bug fixes.
So, if understand correctly, you want to create a user and save it to IS4.
Then you want to call webApi to create a company and finally you must pass companyId to IS4 in the new user.
If you don't need to pass data from IS4 to webapi to create company you can just call webApi first to create company and after that call IS4 passing companyId. (I don't prefer this solution)
If webApi has many transactions with identity it's better to call identity from webApi rather than from SPA. It's easiest and safest directly from webApi.
Related
I have an ASP.net core solution that contains 2 projects and I want to add authentication for both of them:
I want the web app to use cookies-based authentication because it's easy to add.
But when I call an API from the ApiAuth project I want to be authenticated to use it.
WebAuth project contains the basic authentication (login, register...) but I can call ApiAuth project Apis without being authenticated. how can protect the ApiAuth project APIs?
I tried adding [Authorize] decorator but I am getting this error:
So I am thinking about adding a JWT authentication but I don't know if it's the correct thing to do or not?
Any suggestions, please?
If the API requests will come from the web app which was served with a cookie, and if the web and API share the same domain, you can use the same cookie for both. This is preferable to JWTs given that it also has the advantage of using secure, HTTP-only cookies which aren't susceptible to malicious JavaScript.
On the API, you'll add cookie authentication:
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie();
Requests from the web app should carry the cookie as long as both use the same domain, like myapp.com/app and myapp.com/api.
This also requires both apps have the same Data Protection configuration, so they are both able to read the encrypted cookie with shared keys.
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 MVC project and a Web Api project (separate projects). Access to the database is fully realized through Web Api (including authorization and authentication). ASP.NET MVC is a client, Web Api is a server.
So, how to correctly implement authorization and authentication in the ASP.NET MVC project (on the client side)? I read a lot how this is implemented in Web Api (through a token), but I can not understand how to correctly use this token in ASP.NET MVC.
Realize wrap for each request? I also do not know how to define the user role in ASP.NET MVC. Maybe there is some way to rewrite standard methods of ASP.NET MVC authorization to work with the Web Api token? Will the Authorize attributes on the ASP.NET MVC client side work? Suggest please in an example of such an implementation if possible, or tell me how best to implement it.
First of all if you are not in production yet, it might be time to jump to .Net Core 2.x. It does not separate Web API and MVC underground and it's up to date technology.If, for some reason, you can't upgrade the framework, then yes, employ Microsoft.Owin, Microsoft.Owin.Security.OpenIdConnect and all the dependencies.OIdC defines two types of tokens: Identity token, describing a user and Authorization token, giving access to API. There should be some Identity Provider in the system, authenticating users and authorizing clients (such as your MVC APP). Such provider could be external (Google, Office 365 etc), or internal -- you can use free Identity Server 4.x implementation and adjust it to feet your needs. You could even build the IdP into your app.The flow for both .Net Core and Owin OIdC implementations should be identical:
You register all your apps (API and MVC in Identity provider)
User requests an MVC resource, OIdC middleware redirects him to IdP.
IdP authenticates the user issuing identity and access tokens.
MVC validates the Identity token and uses it to create a local Authentication cookie, so the user becomes authenticated in the app.
MVC controller calls some API and put into the request access token, requested from IdP.
API validates the token and responds with requested data.
I would recommend you to use OWIN interface to implement token based authentication for web api and MVC. You should provide authentication token in your web api and give ability to deserialize the token in MVC and Web Api. So, you can find an example open source project here which I developed it about how can you implement token based authentication with OWIN for Web api.
For MVC project, you should follow the same practice by using OWIN.
The best way is to use Azure active directory authentication if active directory is configured for using your application. You can get more info here
I have a website written in ASP NET MVC. It's using ASP.NET Identity to authorize users to particular Controller actions. It's using different claims on users(like roles).
Now I need to write a Mobile App which is suppose to do the same what my website does, so to avoid duplicating code I decided to move all the data access layer to separated Web Api(MVC 6) Project so I can reuse the logic between applications. The question is - is there a way to somehow "Reuse" the authorization I have in my MVC project, like generating and passing some token to Web Api or something ? Re-writting it from scratch would take too much time, which I don't have too much. Any answers/tips/articles would be appreciated.
Yes, but API's do not generally use cookies so you can configure Bearer Token authentication which your API can use. OWIN middleware will look after authenticating the token and populating the User principal in the same way that cookies are handled in MVC.
After that, you'll be able to handle authorization in the same way as your MVC controllers.
I am learning to develop asp.net Web API with AngularJS frontend framework. I have been doing a lot of research on this for about a week now.I have read about oauth 2, owin and other. But now confused which is better.
I have a couple of Question and hope you guys can help me with it.
1) In my application - Only Registered User will be able to have access in to application through log-in with email and password. Can someone please point me to a good resource or article on how to create a good registration and log-in authentication with API.Which is secure enough as i will be gathering user data and storing them.
2) What type of security i need to protect my API, at first the API would be behind the firewall and then ones project is finished it will be open to the world? and also please point me to right direction if possible.
Please note this is not a duplicate question i have been through most of the post on stackoverflow and asking this after i could not find answer.
Any suggestion or help on this is appreciated.
Thanks for all your effort on this topic
You can use token based authentication using Asp.Net Web API 2, OWIN, Asp.Net Identity and AngularJS.
Asp.Net Web API now fully supports OWIN. Katana is microsofts OWIN implementation.
Asp.Net Web API now supports authorization using OAuth 2.0. OAuth is made possible with Microsoft OWIN components.
Are yo confused with the terms Identity,OWIN,OAuth ... here is brief overview of them.
Asp.Net Identity is developed to overcome problems by asp.net membership system. Asp.Net Identity allows us to use different storages(Table storage,No SQL) and allows us to use external identity providers as it uses OWIN.
OWIN is to break tight coupling b/w Asp.Net and IIS. OWIN is just a specification. Katana is Microsoft's OWIN implementation. OWIN sits in http request pipeline. OWIN pipeline has middleware components, where we can mention external login mechanisms.
OAuth was created to remove the need for users to share their passwords with third-party applications.
Note:
Here Asp.Net Identity has nothing to do with OWIN, OAuth and vice versa. They are three separate concepts. Asp.Net Identity is Microsoft's implementation. OWIN, OAuth are open
standard concepts. Because Microsoft has implemented OWIN, OAuth is made possible.
So, Web API 2 uses OAuth bearer token instead of forms authentication cookie, which is more correct in Web API world. Because it allows to use variety of end user devices like mobile devices.
In your case, you can use the default templates provided in visual studio 2013.
1. Create New Project and select Asp.Net web application.
2. Select Web API or SPA template.
3. Change authentication and Select individual user accounts.
4. Click Ok.
Now, everything is configured by default in order to use OWIN, Asp.Net Identity, OAuth. Be cause we use token based authentication, you can find there is no login method available in Account Controller.
To register users, use Register method available in AccountController
To login, you need to post data in following format to
http://example.com/token (Which can be configured in StartUp.Auth.cs)
grant_type=password&username=Alice&password=password123
After login, we recieve bearer token, which we need to send with authorization header with every request to access protected resource.
As you are using awesome frontend framework AngularJs, you can save bearer token in local storage, and you can write a http interceptor service, which takes care of sending bearer token with each request.
Here registering the user is taken care by Asp.Net identity, where as authenticating user is taken care by OAuthAuthorizationServer which is present in Providers folder by default.
Bearer tokens, that we recieve are not towards a specific client,so any one can intercept them. So use them only over SSL.
Please go through this links
http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
http://bitoftech.net/2014/06/09/angularjs-token-authentication-using-asp-net-web-api-2-owin-asp-net-identity/
Vs2013 webapplication project template comes with a good owin setup. I suggest to look into that