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?
Related
I uploaded an App Service in Azure, already with working API (with JWT Token system). It's all fine and working with <mywebapp>.azurewebsites.net (Web Service URL) for the front-end website, and <mywebapp>.azurewebsites.net/<api-route> for API access.
And then I've read about API Management Services so I registered my web app though there. Now I can use the portal to test my API, it even has its own token system, but my JWT token system is still in effect, so now I would need to do 2 authorization methods to use this API? I've also got a new domain: <mywebapp>.azure-api.net/<api-route> (Gateway URL) which now created the confusion.
My question is, is it okay to just use the same web app as front-end and API, like what I did in the App Service example? Or is it more pretty to create a separate web app to use in API Management Services (and use the default token system)?
I created my front-end with Razor using this tutorial: https://learn.microsoft.com/en-us/aspnet/core/tutorials/razor-pages/?view=aspnetcore-5.0
And then I added the API on top of it using this tutorial: https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio
For your scenario since you only have one API, you can directly call the API endpoint from the Web App and completely get rid of the APIM. I do not see a need for APIM here.
APIM helps if you have multiple apis and you want to abstract all of them under one URL so that your frontend Web layer doesn't have to remember multiple API urls.
For example, if you have 3 different API URL then you can abstract all under one APIM URL like below-
apimurl.azure-api.net
-- api1url.azurewebsites.net/hr
-- api2url.azurewebsites.net/finance
-- api3url.azurewebsites.net/payroll
Then your Web UI just can call apimurl.azure-api.net/hr
or
apimurl.azure-api.net/finance
For your case make it simple and go with App Service URL. If you want to test your API just use Swagger UI.
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 an existing WEB API 2 project with JWT authentication.
how I merge my WEB API application so it's similar like Administration project.
the route will be something like localhost/api/[myApiRoute]
I know there's an alternative way using plugin, but I got a dead end implementing JWT and my customization handler.
So I ended up by adding a Web API to NOP.WEB project.
The steps I needed to perform were:
Add Web API Packages
(How to add Web API to an existing ASP.NET MVC 4 Web Application project?)
Add OWIN Packages
(http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/)
Configure the Startup.cs
now you can use [System.Web.Http.Authorize] attribute to authorize your API using OWIN Authentication.
I also add new folder called API and put all API files there (Controller, Models, Provider, Handlers, etc.) so it would easy to maintain.
For API routing, I'm using Attribute Routing (http://www.asp.net/web-api/overview/web-api-routing-and-actions/attribute-routing-in-web-api-2). you can add config.MapHttpAttributeRoutes() at Startup.cs
I developed a website using ASP.NET MVC5 with Entity Framework and Microsoft Identity. Now I need to add Web API to this project for mobile app development using RESTful architecture. My questions are:
Does Api controller and Mvc controller shares the same request pipeline?
Can I separately implement the Cookie based authentication for website and the Token based authentication for Api?
If I deploy the website on IIS, does this mean Web Api will also be automatically hosted by IIS?
I will try to answer your questions:
No, they using different pipeline. For MVC check this document
and for WebAPI this one. Basically MVC will use same pipeline
as previous ASP.NET implementations and Web API using OWIN based
model, however since you host it on IIS request still will go
through modules and etc., but it's better not to relay on them. MVC
and Web API pipelines merged in ASP.NET 5, where all of them uses
OWIN
Yes, it's up to you how authorization will be implemented. You can
even separate authorization for different WebAPI controllers: just
create different authorization filters
Yes, it will be configured with OWIN implementation, but hosted on
IIS
I have been researching Authentication & Authorization using ASP.NET Web API 2 for about 2-3 weeks & after lot of researching & reading I am able to agree upon the basic architecture for my project.
My project currently consists:
ASP.NET Web API 2 backend (OWIN/Katana)
Android App
I am referring Cross-client Identity to generate access_token & refresh_token for the Web API 2 project; where access_token is generated on Android App for the Web API using GoogleAuthUtil.getToken()
The access token (bearer) doesn't work on Web API and is remarkably shorter in length as compared to the one generated at the Web API side using OWIN Middleware.
I think I am accurately following all the steps correctly, unless I am doing something fundamentally wrong.