I want to implement token based authentication for an ASP.NET Web API project.
I have come across 2 implementations the Katana/OWIN middleware, and another one called Identity Server 3
Would you recommend one over the other? My Web APi is only going to be accessed via the SPA. But I would like to have users login from a database store or using a 3rd party provider.
What are the benefits of Identity Server 3 ? Also it seems that IS3 acts a separate service/server. Does that mean there will be more roundtrips for authenticating?
It sounds as if you want to accept identities from external providers as well as maintaining an internal database.
For external providers, you will need to validate the tokens that arrive. OWIN provides support for obtain the artifacts you need to validate a token by retrieving metadata from the IdentityProvider.
Your Web API should be able to obtain an access token and present it to your application by using 'OAuth Bearer'. This should be independent of using a Database.
Related
I work on an application where I have a separate MVC layer and Web API Layer, both have the same authentication mechanism, I have chosen the individual accounts authentication option while adding the projects. The web api service layer will be directly accessed by some other mobile clients also.
But when the user logs in through MVC he should be able to access Web Api seamlessly, but I don’t want to really pass the username and password from MVC to the Web Api layer, I am told it is a bad practice. but i need to authenticate and authorize my user, so the only option i have thought of is to have a default account at Web API level to issue tokens, and this will be called from MVC post the authentication and a token will be returned which is written to a cookie in the client. Now the Ajax calls from the UI can use this bearer token and get the job done.
The only glitch I have here is that, because I am using a default account I need user details again for authorization at service level, though I am doing authorization at my UI level, the user can spoof the system. I was lost here and came up with a solution like, when the user logs in to MVC will send across user details also along with the call to get the WebAPI token and issue another token to the user so that the user uses both of the tokens to make a call to web api from MVC.
I am not sure if this works or if it is even the best way. I just wanted to check, how I should go from here. Any help on this will be really great.
This is a really good example of integration - I know they use Angular as the client but you can learn from this:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Check this section to see how they decouple the API from the front end (Part of the same article).
http://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/
I have a RESTful API written in ASP.Net that implements OAuth 2 for authentication, and it's currently accessed through a web application. I've also got a legacy desktop client that accesses the same resources directly (not through the RESTful API and without OAuth, but using the same login credentials and hitting the same database). The requirement I'm trying to meet right now is to allow a user to click a link in the desktop application in order to open the web app to a specific screen, and when they do, to have the web app authenticate automatically so that they don't have to manually log into it (since they've already logged into the desktop app).
I'm trying to work out how I can handle this within the constraints of the framework. I'm not too familiar with OAuth 2 in general, but from what I understand I shouldn't share tokens between clients and there are no flows specifically for this kind of hand-off (unless I'm missing something). Worst case scenario, I could generate a temporary token outside of OAuth that's used by the web client to authenticate rather than a username and password, but I'm hoping to avoid stepping outside of what's already in the framework to do what I need to do.
So the question is this: is there some decent way built into the OAuth 2.0 framework to handle this sort of "handshake" between two applications, or should I just build my own method of dealing with it?
Using temporary one-time tokens is actually part of OAuth spec (authorization_code grant type). In this case this short-lived code can be exchanged for access_token (and refresh_token). You will have to implemenent generating and validating of this authorization_code.
If you are using OWIN OAuth middleware:
You can generate the code at separate API endpoint accessed by your desktop client app.
After receiving token, pass it to your browser and direct it to auth endpoint with grant_type=authorization_code over secure connection. Example: call Process.Start("https://example.com/ExternalLogin/authorization_code_goes_here"). At the webpage redirect user to your OAuth Token endpoint with grant_type=authorization_code.
AuthenticationTokenProvider.Receive will be called, in which you will validate your token. (Example code here).
After successful validation OAuthAuthorizationServerProvider.GrantAuthorizationCode will be called, in which you will process the authenticated user in the same way you process it with grant_type=password.
Remember that your token validation logic should ensure that your tokens are short-lived, usable only once and transmitted over secure connection.
This is sometimes called "single sign-on" if you want to research this topic further.
We have multitenant asp.net MVC web site which supports multiple partners. Currently we are using forms authentication to authenticate users. Now some of the partners have asked for single sign on support with SAML.
I did quick POC to test it against “Thinktecture” identity provider. All I did was to install “Identity and access” extension for VS 2012 and configure the identity provider. I noticed that the extension added configuration settings like URL of the IP and realm in the web.config file. It also added “WSFederationAuthenticationModule” module to handle the authentication. This module was handling all the redirects and the validation of response behind the scene.
In my case since we will have multiple identity providers, depending upon the partner, I will be choosing the Identity provider. The URLs of the different IPs will be stored in the database. I cannot list all the IPs in web.config. Hence I need mechanism in which I can redirect user to appropriate IP URL and once the IP posts back the result, verify the result and retrieve user information through claims. I don’t want to do the XML parsing of the result and validate the response, but just want to call methods in “WSFederationAuthenticationModule” to do the heavy duty work. But I am not sure which methods will be useful for me. Can somebody help me out or list of the sequence of methods I need to execute to achieve this?
Take a look at my simple example
http://www.wiktorzychla.com/2014/11/simplest-saml11-federated-authentication.html
The trick is not to have the WSFam module in the pipleline but rather use its api to trigger redirects and consume responses. If you follow my code, you'll see there are two clauses
// wsfed response or not
if ( !fam.IsSignInResponse(...) )
// redirect to provider
else
// create local config and validate the incoming token
This simple example is perfectly suitable for multitenant scenario, in fact we use ws-fed daily in multitenant environment and most clients are based on this core approach.
Namely, creating the SecurityTokenHandlerConfiguration programatically in the branch that consumes the response gives you total control over how you validate tokens for different tenants.
I have REST web services exposed by APIs controllers in my ASP.NET Application. These services are useful for me to synchronize my business layer with my view layer.
Now I want to make them more secure, because I feel like all my data is exposed and that anyone can have access to them, if only he types the http url of the web service. Is there any username/password security mecanism for my web services? Or is this done via a certain configuration to IIS?
If you would like to create your own security mechanism then it would not be to hard to authenticate using tokens in the http header. For example, you could use a public/private key scheme and hash a few items that change frequently such as DateTime and input parameters and the resource url itself.
.Net provides ways to place your security checks prior to reaching your service methods so you don't even have to check the token in the http header in each of your methods. They will only be invoked if the request is authenticated.
I am going to be using Web API for an upcoming project and was asked to integrate an existing STS provider into the equation as my authentication mechanism. Therefore my Web API would be the RP (relying party). I don't need any support to provide the actual token (like creation of STS Provider), just need to incorporate claims based authentication to the configured STS provider and use it in my Web API REST based service.
Does anyone know if this is possible, and some examples on how to implement this? I see full examples with creating a STS provider, but like I said it already exists. I just need to trust it and use for authentication purposes.
Depends which protocols your existing STS supports. You need to find that out.
Basically you need to do this:
request a token from your STS (from within your client app)
send the token to the Web API
validate the token inside Web API
The thing you need to find out is if 1. works with your custom STS - then we can talk about 2 and 3 ;)