We have planned to implement authentication in our API using OAUTH. For this purpose I read so many articles on web to explore it. After read these articles what I am understanding is
Send credentials to authorization server and after successful
authentication it will send you the access token.
Use this access token for further calling of your api methods.
To authenticate our api user needs to pass the following parameters.
Authorization Token
Employee ID
What I am thinking is to pass these values via request headers. Problem is that these request headers can easily be viewed in browser console and someone can misused it easily. Please suggest Is this the right way to authenticate api or we used something else for this purpose?
Reading this question, #Pinpoint's answer and the further discussion on comments, I'm well aware that natively we can't add an identity provider to our apps developed with ASP.NET 5. One possible replacement for the legacy OAuthAuthorizationServerMiddleware is then provided by the AspNet.Security.OpenIdConnect.Server as I've found in many places.
Now, there is one point that I'm still unsure about all this because I'm really not an expert in security, so my knowledge about OAuth is not very deep. My doubt is the following: is it possible to use an external identity provider when using OAuth to protect one RESTful API?
Notice that I'm not talking about adding social login to one website, I'm talking about using one external identity provider in one RESTful API.
My point is, this makes me a little confused yet, because I always thought this should be a concern of my app.
So my question here is: when using OAuth and ASP.NET 5, is it possible to use an external identity provider, other than implementing one? If it is possible, how this works in short? I mean, my app still needs to be able to manage the identities of users, in the sense that it needs to manage claims and so on.
In that case, if it is really possible, how the flow would be? The external identity provider should issue the tokens? But how my app would be able to verify those tokens and manage users identities?
EDIT: One of the reasons I feel unsure about that is that when we use the UseOAuthAuthentication extension method, we set up one callback path which is described as
The request path within the application's base path where the user-agent will be returned. The middleware will process this request when it arrives.
Now, if we are developing a site, then this really does make sense. The person goes there, click a button to login with a provider like Facebook. The user is redirected to Facebook's page and then after he logs in, he is redirected to some page of the site.
On the other hand, with a RESTful API this is meaningless. There is no notion of being redirected.
This makes it seems that the usage of external providers is only for sites and not for RESTful API's. This is the main point of my question.
My doubt is the following: is it possible to use an external identity provider when using OAuth to protect one RESTful API?
Yes, it's definitely possible. This is exactly what you do when you use Azure Active Directory to protect your API endpoints:
app.UseOAuthBearerAuthentication(options => {
options.AutomaticAuthenticate = true;
options.Authority = "https://login.windows.net/tushartest.onmicrosoft.com";
options.Audience = "https://TusharTest.onmicrosoft.com/TodoListService-ManualJwt";
});
The next legitimate question is: if you can use the tokens issued by AAD to protect your API, why couldn't you do the same thing with Facebook or Google tokens?
Unlike Facebook or Google, AAD issues completely standardized tokens named JWT tokens that the OAuth2 bearer middleware can "read" and "verify" to determine whether the token is still valid and was really issued for your API (i.e if the audience attached with the token corresponds to your API. You can control this value using the resource parameter when making your authorization request).
You can't do something similar with FB or Google tokens, since they are totally opaque. Actually, it's not really surprising since these tokens have only one objective: allowing you to query FB or Google APIs, not your own ones (these social providers don't allow to set the audience of the access token).
Since you can't read the token yourself, the only option is to ask FB or Google whether it is still valid to make sure your API doesn't accept invalid tokens. That's something you can (easily) do with Facebook as they offer a "token inspection endpoint" you can query for that: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow (see the Inspecting access tokens chapter). This way, you can ensure the token is not expired and determine the user corresponding to the token.
Sadly, this approach has two downsides:
You have to make an extra HTTP call to the Facebook endpoint to validate the access token, which implies caching received tokens to avoid flooding Facebook with too many requests.
As the access token is not issued for your own API, you MUST absolutely ensure that the access token was issued to a client application you fully trust, or it will allow any third party developer to use his own FB/Google tokens with your API without having to request user's consent. This is - obviously - a major security concern.
You can find more information in the last part of this SO answer (it's for Katana and about Dropbox, but you should get the idea): OWIN/OAuth2 3rd party login: Authentication from Client App, Authorization from Web API
So my question here is: when using OAuth and ASP.NET 5, is it possible to use an external identity provider, other than implementing one? If it is possible, how this works in short? I mean, my app still needs to be able to manage the identities of users, in the sense that it needs to manage claims and so on.
In that case, if it is really possible, how the flow would be? The external identity provider should issue the tokens? But how my app would be able to verify those tokens and manage users identities?
To work around the limitations mentioned in the previous part, the best option is - as you've already figured out - to create your own authorization/authentication server. This way, your API doesn't (directly) accept FB or Google tokens but the tokens issued by your own server, that can possibly redirect your users to FB or Google for authentication.
This is exactly what this sample does: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/tree/vNext/samples/Mvc
The user is invited by the client application (Mvc.Client) to authenticate with your authorization server (Mvc.Server) so he can get an access token to later query the API (also in Mvc.Server). For that, the user is redirected to your authorization server, which itself offers you to authenticate with Google or Twitter.
When this external authentication step is done, the user is redirected back to your authorization server (Mvc.Server), where he's asked to give his consent for the client app (Mvc.Client) to access his personal data.
When the consent is given, the user is redirected back to the client application with the access token you can use to query the API endpoint.
I am developing an asp.net web api app, and using OWIN and identity to implement oauth for my aplication security. For each registered user, I also save a client id and hash as described here. But I dont want other developers be able to use my api and create their own app using the client id (and other credentials) they have.
Is it possible ?
First thing first, you have to encrypt your network traffic between mobile device and API. Because attackers can obtain sensitive data (which is API Token in this case) via proxy . Also you need to do SSL Pinning because of you need to be sure about public key is yours, otherwise attackers manage to get sensitive data again with same method. ( Please check out : https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning )
You shouldn't authenticate users with username/password. I suggest to you use api key, therefor you can send user actions to server side like following patterns.
https://example.com/api/APIKEYOVERHERE/action
Als you can watch this talk about Secure Your API - Tips for REST + JSON Developers.
https://www.youtube.com/watch?v=FeSdFhsKGG0
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.
What is a good way to transfer an authorization key to a server? I'm building an REST-API right now and I'm stuck how the user can authorize on that api. He will get an authorization key (thats not the problem), but what would be a good way to pass this key to the server? As a GET parameter, as an HTTP Header field, as a cookie?
Which way is easy to handle with most of programming languages (e.g. I want to use the API with php or ajax..)
i suggest to send via HTTP POST, and if possible then encrypt it before sending it and decrypt it on server on need basis
You could use the HTTP Basic authentication scheme, which uses the Authorization HTTP header. With Basic authentication, the client must provide its credentials on each request. so you might prefer the Digest authentication scheme, which is a little more secure.
Without more details, I might recommend OAuth 2.0 with the Client Credentials grant type. Basically, the client uses Basic authentication with its client credentials once to receive an access token, and then it uses the access token on subsequent resource requests. Typically the access token is submitted using the Authorization HTTP header.
OAuth is really an authorization framework, but it provides a good solution for API authentication also, and you might find its authorization tools useful for securing access to API resources. It could be that the Authorization Code grant type is applicable to your use case as well.
Related: Best Practices for securing a REST API / web service