We are building an application with Angular 10 based front-end and .NET Core 3.1 based Web APIs. For Authentication and Authorization we want to use ASP.NET Core Identity. I want to know if we can have Identity system integrated with our Web API project and use Authentication method via Web APIs to generate JWT and later Authorization. I am wondering if this is good approach to follow or there is any security flaw in this approach. I get this doubt because I have read somewhere that the Authentication must be over server rendered pages instead of JavaScript based front-ends.
Currently we are developing a project that has Web API which will be consumed by both web application (Asp.Net MVC) and mobile apps (iOS and Android).
We are planning to implement oAuth in Web API to handle user authentication and authorization.
Usually we would go with ASP.NET Identity Framework if it is only a MVC application but since the authentication will be taken care in Web API, how do we maintain the user session in MVC?
Is using the Session Management still the standard way to do it?
We are planning to get the token from the Web API and save it in the MVC session to check if the user is authenticated or not? If I use the Sessions, do the [Authorize] attribute work the same way as it works when using ASP.NET Identity Framework?
I'm looking for a way to do token authentication for the Web API controllers I have created within an MVC 5 application (I need a way to do it without creating a separate Web API project within the solution). My endpoints are in the Controllers folder at the project level and the controller types are Web API 2 Controllers. How can I generate a token for a user that logs in on the mobile application that uses the Web API and use that token for the endpoints that are contained in the API?
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
We currently have an ASP.NET Core MVC app in combination with IdentityServer4 for authentication. The user authenticates via IdentityServer (with the HybridAndClientCredentials flow) to ADFS before it has access to the MVC application.
The SignInScheme on the MVC client is set to the values "Cookies".
We would like to extend our MVC app to host multiple Angular apps. Sometimes even more than 1 Angular app per MVC view.
The angular apps will call seperate ASP.NET Core Web API's on behalf of the user.
My question is how does the angular apps know that the user is already authenticated in the MVC application, retrieve the access token and call the API's on the user behalf?
I have been playing around with solution Scott Brady came up with but there seems no integration between the MVC app & Angular app. The Angular app will try to authenticate to identityserver and expect a callback on a particular page.
I am looking for a solution how to share the accesstokens between the MVC app and the angular apps but I am stuck. Any help is much appreciated.
If they have to sign in via the server-side hybrid flow already then the simplest way would be an endpoint in your MVC app that is cookie-secured that the client side app can call to get the access token.
Another approach is to use oidc-client-js and have the client side Angular app obtain its own token.
You could abstract this away from the client side app itself so it's easy to change the mechanism later if you need to. As it happens we use a combination of server side and client side flows and it works fine.