I am trying to develop a VueJS SPA app with WebApi 2 as backend and would like to implement OWIN authentication.
The front end app should be accessible to intranet users (Windows authentication) and based on the roles (already existing table that is stored in the database- which I would like to add to claims), the corresponding pages should be accessible to user.
Most of the examples use Forms Authentication, which return token, which are not helpful in my situation
Follow the link http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/ for token based authentication.
Related
Currently I have created a WebAPI Project using identity framework and I have setup tokens to be returned when authenticating with the API.
So now I am looking at creating a standalone MVC application that will allow the user to make calls to the WebAPI to get back end data.
The goal is to separate functionality so that other applications can also start interacting with back end data through web calls.
So the confusion now is how do I setup my MVC project so that I can use the Authorize attributes on controllers with the token received from the WebAPI. I think I need to enable bearer tokens in the ConfigureAuth method in Startup.Auth.cs. However will that be sufficient enough? Or do I also need to enable the cookie authentication?
MVC and Web Api are fundamentally different when it comes to authentication. With Web Api, the bearer token has to be set in the header of the request, but this is not an issue as all API requests are done programmatically by the client, i.e. there's human-intervention involved in setting up the client to authenticate the request properly.
MVC is a different beast in that the actions are accessed generally via a web browser, which will not automatically affix a bearer token to the request header. What it will do is pass cookies set by the server back to the server. That's why cookie auth is used most typically for MVC web applications.
What you should do is enable cookie auth for the MVC site and then set up your sign in action to authenticate via the Web Api. When you get back a valid auth from the Web Api, then you can manually sign in the user via the Identity API:
await SignInManager.SignInAsync(user);
I have a Single Page Application for non-/mobile html5 browsers getting data from a RESTful HTTP API with asp.net web api. We use OWIN self hosting running in a windows service.
I do not want cookie based authentication. I would like to authenticate the user and give him a json based access token with its claims/permissions to edit/create/delete/show certains things in the UI.
I do not need external login provider. Our user will authenticate with username and password not their google email...
Now I askmyself should I go in direction thinktecture and identyserver, or asp.net identity or...OWIN and ExternalBearer authentication, I am lost here.
What would be your recommendation basing on my information?
IdentityServer is suitable for scenarios where you have multiple applications and want them to authenticate against a single STS, basically if you want SSO. The scenario you described is achieved in IdentityServer by OAuth. That is you define an application you wish to use IdentityServer to authenticate, and then create an OAuth client to get access tokens for accessing that application. If that's not the case then you're probably better off avoiding the complexity of introducing a 3rd party component to do that work. We're using IdentityServer to authenticate users of 3 different apps 2 SPAs and an MVC application. Also, you realy can't seperate OWIN and ASP.NET identity in this case. The OWIN middleware will give you the tokens and it will be using ASP.NET Identity as a user repository to authenticate users, so OWIN is just doing the job of providing tokens and using ASP.NET Identity to authenticate users.
Ok, the situation is this.
We already have an existing ASP.NET MVC 5 site with Custom Forms Authentication, Logon, Registration etc with a custom database for roles and profiles already implemented.
We now are adding some new functionality to the MVC site and we decided to use Web Api 2 OData 3 endpoint which lives in another domain. The Web Api currently doesn't include any authentication but we need to be able to map the requests to a certain user to get his roles etc from the backend. The MVC and API sites use the same backend.
What we would like to accomplish is, that when the user logs on in the MVC site, the MVC site calls the Web Api server-to-server with the user's credentials and receives a token that the client can then use to call the web service with.
When API receives a request with the token, it can then map the request with the user in backend and do authorization.
As far as I understand it, Simple Web Token (SWT) could pull it through. But considering the environment, .NET 4.5.1 / Web Api 2 / OData 3 with Entity Framework in Azure Web Role, I started thinking is this SWT something I should really use or if there is any NEW technologies recently published that could easily pull this through. I don't want to add any unnecessary 3rd party dependencies to the project if the .NET stack already contains something like it.
So, what would be the simplest way of pulling this kind of authentication through without adding unnecessary dependencier to the project.
The solution we are looking for, is only temporary meanwhile we redesign our authentication scheme. So we are looking for something really simple to implement that works with least dependencies that need to be removed later on.
I'm using this in a project I'm currently working on. I use the OAuth 2.0 OWIN Middleware component that ships with Web API 2.0 (if you add a new Web API project with Authentication enabled, it includes the base infrastructure).
You would use the Resource Owner Password Flow as defined in the OAuth 2.0 specification. Basically you request a Token from the Web API OWIN Middleware sending:
client_id - identifies your MVC endpoint
client_secret - identifier your MVC endpoint
username
password
And in response you get a bearer token. The token generating is based upon a claims principal, the OAuth middleware component has predefined hooks for adding claims. This token now needs to be added as authorisation header to each response. On the MVC side you might add this to session so that it's always available to make backend API calls in the context of the user associated with an incoming HTTP request. If you're using WCF Data Services Client, you'll need an authorisation service/manager or similar that you can hook into OnRequestSending and OnResponseReceived events, so that you can insert that bearer token into the HTTP headers.
You can customise the OAuth Middleware component as you need to quite easily, it took a bit of time to figure it out as it's not too well documented, but downloading the Katana source code did help a bit as the source code does have some good documentation.
The nice thing about it all is that you simply need to enable HostAuthenticationFilter and add Authorize attributes on the Web API side and it's ready to go. You can get access to the claims principal object and use claims as identifying pieces of information for your user - e.g. identity, roles, other attributes etc.
To get started, look at http://www.asp.net/vnext/overview/authentication/individual-accounts-in-aspnet-web-api
Also as a wrap, I did consider the use of JSON Web Tokens (JWTs) as there is an OWIN library available for generating and parsing these. The use case here would be that you authenticate, get a JWT back, and then use the JWT to get an OAuth 2.0 bearer token. The JWT is useful if you want to move authentication elsewhere, or if you want to get additional information about the user at the MVC side of things.
I am working on a Windows Phone 8 app and a ASP.NET MVC 5 website and each of these will access a WebApi service (WebApi 2). The website and WebApi are based on the templates provided by VS2013 RTM and have been setup using the "Individual Account" authentication option available in the project template.
The template sets up the WebApi project to enable bearer tokens, application cookies and external login cookies, etc, and the exposed actions have the Authorize attribute on them.
My two questions are:
1) If I were to use Azure Mobile Services to authenticate a user using Google/Twitter on the WP8 application how can I get the WebApi to allow the authenticated user to access the actions?
2) Same as #1, but from a ASP.NET MVC 5 website perspective?
From I what I can see it would appear that each request requires a bearer token. To get this token would I be correct in thinking that I would access the "token" endpoint exposed by the WebApi to get the token and that would need to be passed with each request?
For 1, you can use azure mobile service WP8 sdk to launch a browser control to authorize user from external site. The code should be similar with WebAuthenticationBroker in windows store app.
For 2, the web api template with individual auth is using an implicit flow in OAuth 2.0 to return the application access token back to client. In MVC app, you can redirect user to
http://<web api domain address>/api/account/externallogin?provider=Facebook&redirect_uri=<your callback url in MVC app>&response_type=token&client_id=mvc.
And in your MVC view, you need to use javascript to get access token from url fragment, which won't be sent to server. In your web api server, you need to allow the client id and the callback url in ApplicationOAuthProvider.
For both 1 and 2, you are not using token endpoint to get the token. You are using the authorize endpoint to get token by implicit flow.
I have a website with some areas that require a login via forms-based authentication, using my own provider that connects to the database.
The website is in preview so I want to protect the entire site via basic auth to prevent unauthorized access before it goes live.
The problem is when basic and forms auth is on the pages that will be public go to the forms login instead.
How can I keep the forms based authentication for member login and portal access, but protect the entire site from public access before go-live by using basic auth?
I think you should be able to satisfy your use case in the following manner.
Within the site .Net Authorization Rules create a Deny rule for anonymous users.
At the site Authentication enable Basic and Forms authentication. Disable all other authentication types. This should require all users to be authenticated with basic authentication to use the base site and then require forms login to the parts of the site that requires your custom authentication.