i'm building a web Api with node.js and a client to consume the service with Ember.js. This client is considered to be "The Official" as the service is intended to be consumed also by third parties (like twitter, facebook, g+, does).
My concern is the security of the API.
The approach i'm trying to accomplish is to implement oauth 2.0 with the oauth2orize module to give access to every registered client the user authorises. The problem with this is the user would have to authorise the official client too, like it was a third party client. I want the authorization to be transparent to the users login into the official client.
Is there a way to avoid the authorization or give it automatically to the official client for every registered user?
Is this the best approach?. My other idea is to use basic (user:password:cookies) authentication for the official client and leave the authorization part only for third parties. In that case, how would i know if a request is coming from a third party or the official client to use the proper authorization schema?
thanks in advance.
Related
Due to the lack examples of oauth2 in node.js, I can't decide where to implement the oauth2 service. Also, I wanna know what is the meaning of provider in oauth2 and when to create a new one and when to use a pre-made one like google.
I tried to implement a provider in the server-side but I didn't know how to test it.
If there are any useful resources I would be happy to take them.
You should use Open Id Connect (Authorization Code Flow + PKCE) in your Angular app. You should validate OAuth 2.0 access tokens in your API. Both of these components should interact with a 3rd party Authorization Server. There is a learning curve and my tutorial + code sample may help you - feel free to post back if you get stuck: https://authguidance.com/2017/09/24/basicspa-overview/
oauth2 provider means wich service to use to auth, eg server-side will mean the user creates an account on your Server, google would mean users sign in with their google accoutns to your site.
We have a simple setup: An authorization server based on OAuth 2.0, which currently only supports the client_credentials grant type. Then we have an API, the resource server, which is protected by requiring an access token from our OAuth server.
All use-cases for our API so far, have been pure machine-to-machine communcation, where it's simply our customers servers running batch jobs.
Today I had a meeting with a new customer. They have an SPA that seemingly does not have its own backend server. It uses AWS for authenticating, and seems to return a JWT, but from what I can tell, they make a lot of API calls directly to publicly available services, and then the logic is all performed in the SPA.
We ideally would've liked them to simply register a single OAuth client with us, so that when users make a request that needs one of our APIs, the request is first routed to their server, which performs the lookup, and then uses their client's credentials to contact our server. But they would prefer to not have to set up a backend. In this case I'm kind of at a loss for how we sensibly let them integrate with our system. They would prefer to send their user's JWT to our system, but I don't think they understand that we would need their key to verify the user's signature in that case, and we don't want to have to create new APIs simply for this purpose.
Would very much appreciate any advice on this issue - thanks very much in advance for any help.
We ideally would've liked them to simply register a single OAuth
client with us, so that when users make a request that needs one of
our APIs, the request is first routed to their server, which performs
the lookup, and then uses their client's credentials to contact our
server.
Your recommended approach is the right way of doing it with Client Credentials Grant.
They would prefer to send their user's JWT to our system, but I don't
think they understand that we would need their key to verify the
user's signature in that case, and we don't want to have to create new
APIs simply for this purpose.
If the previous approach doesn't work, I'm afraid that this is the only way of doing it. You will need to implement a Proxy to validate the JWT (You should be able to get their public key to verify the signature). You can do this in AWS itself, using AWS API Gateway + Lambda to verify the JWT to and forward the request to your existing backend with Client Credentials Grant where you don't need to pay anything upfront.
Background
I'm building a .NET MVC enterprise web application that must have the ability to authenticate users from different companies. One of the major requirements was to ensure that users don't need to create and remember new credentials to use the application, instead they should continue to use whatever credentials they use to access applications within their company intranet.
Since the application will be hosted on the extranet and needs to handle authenticating against multiple domains (i.e. multiple Active Directories), we are expecting each client to set up a security token service (AD FS) that the application can interface with to implement claims authentication.
The MVC application will check if the user is authenticated, and if not, start the workflow that ends with the MVC application being given a SAML claim being associated with the user.
Problem
At this point, the user is authenticated and given access to the MVC application. However, the application itself is a modern day web application that uses quite a bit of JavaScript to consume a .NET Web API that handles most of the business logic. My main question is how I can secure this API. I want to make sure the only requests being sent to this server are being sent from a valid source, and that the user consuming the service has permissions to do so.
Current Solutions
There are two approaches I can take to consume the API:
Straight from JavaScript (Preferred solution)
Route the request through the MVC server, which will then forward it to the API.
In order to pick an approach, I first need to find a way to secure the API.
HMAC Authentication
The most straight forward solution I've found is HMAC Authentication - http://bitoftech.net/2014/12/15/secure-asp-net-web-api-using-api-key-authentication-hmac-authentication/. However, this approach requires all API requests to come directly from the MVC server, since the secret key will need to sit on the MVC server.
OAuth 2.0
The second approach I can implement is some flavor of OAuth 2.0. The flavors I'm familiar with can be found here http://alexbilbie.com/guide-to-oauth-2-grants/:
Authorization Code
Implicit
Resource owner credentials
Client credentials
Authorization Code Grant
This is not the approach that I want to take. The MVC application has already received claims for the user - they shouldn't have to do it again just because the API needs the claim. (I have a followup question asking if I can simply pass the claim to the API server)
Implicit Grant
I like the way this approach sounds, since I will be able to execute API requests in the client (i.e. JavaScript code), however it suffers from the same problem as the first approach.
Resource Owner Credentials Grant
This approach is out of the question - I don't want either the MVC application or the API to ever hold onto the user's credentials.
Client Credentials Grant
This approach is the only reasonable OAuth approach listed - however I fail to see a major difference between this approach and HMAC authentication detailed above.
Questions
Have I correctly set up the MVC application's authentication structure? Specifically, in this context is it appropriate to have AD FS handle authentication and respond with SAML tokens representing user claims?
I plan to store user data in the server's session. Can I also store the user's claim in the session, and then somehow send that up to the API for authentication?
If I can pass the claim from the MVC server to the API server, and the API server can correctly authenticate the request, is it safe to pass the claim to the client (browser / JS code) so that consuming the API can bypass the MVC server?
Is the HMAC Authentication approach the best way to go?
Yes, using ADFS or any IdP products as an IdP for your application is a good way to implement SSO. Doing this way help you delegate all the federated access management as well as claim rules to ADFS.
Yes, you can store claims in session and somehow send them to the WebAPI. Please note that if you are using WIF, it already stores claims in Thread.CurrentPrincipal as a ClaimsPrincipal object. Another thing is that I assume you only want to somehow send the claims only, not the whole SAML2 token.
I would say it is as safe as the mechanism you use to protect the token on the client side. Check https://auth0.com/blog/ten-things-you-should-know-about-tokens-and-cookies/ and https://security.stackexchange.com/questions/80727/best-place-to-store-authentication-tokens-client-side for more details.
I can't say if it is best for you, but it seems to be a viable way, given that you have control over the WebAPI too. However, it also seems that using JWT token would be easier: https://vosseburchttechblog.azurewebsites.net/index.php/2015/09/19/generating-and-consuming-json-web-tokens-with-net/. Talking about JWT token, you can also ask ADFS to issue it for you: https://blogs.technet.microsoft.com/maheshu/2015/05/26/json-web-token-jwt-support-in-adfs/.
I'm a bit confused about how to properly and securely authenticate users using my REST API and provide and option to authenticate using other OAuth 2.0 providers as well (e.g. Facebook, Google, etc.).
Scenario
Users interact with a web application which should consume my REST API. Users should be able to login and perform CRUD operations both using username/password and by using 3rd party services such as Facebook. I will be using SSL to encrypt the traffic to the website and the API.
Without taking the 3rd party login services in consideration and by studying the various questions already asked here on SO, I thought about handling user authentication as in the picture.
Technologies and current idea
The REST API is written using JS using NodeJS and Express. The WebApp provided through another NodeJS instance is mostly AngularJS with templates which consumes the REST API.
My current idea is to let the WebApp handle the login sequence and let Facebook save their token in my DB using the callback. But this solution smells too much of workaround!
Questions
Is the authentication sequence depicted in the image correct?
How is the above authentication sequence compared to the Resource Owner Password Credential flow in OAuth2.0? Is it worth using OAuth2.0 instead of it?
How can I integrate login through 3rd parties (i.e. Facebook)? Any suggestion or (better) example?
References
passport.js RESTful auth
Login with facebook and using oauth 2.0 for authentication of REST api calls
And many others here on SO :)
My 2 cents..
The process looks good to me.. I would re-issue the token on each sign in and also keep it inside a database so tokens can be revoked easily.
Use PassportJS. Its got support for OAuth flows and supports many 3rd party integrations like FB, Twitter, Github etc..and since its a nodejs middleware.. its integration will be very tight within your application..
Background: I am using node.js and express to create an API. I have implemented OAuth in my API server in a standard consumer/user key/secret fashion (the same way Twitter, Facebook, etc. do). I expect 3rd parties to connect to my API, again in the same manner as these common APIs.
Normally, a client would connect with an application token/secret (eg, you create a Facebook app as a Facebook developer and these are given to you). However there are times when the client cannot provide a secret for the application because the code is implemented in an insecure fashion. Specifically, I am referring to Javascript libraries. Eg, developers do not want to expose their application secret in Javascript code because it is plaintext and could be read by malicious users.
I've noticed that Facebook avoided this problem. The developer needs to provide only an application token (not secret) to the Javascript library. I do not understand how to provide a similar option for my API without fundamentally making my library insecure. Namely, if requests are being made by a Javascript client library to an API without providing a well-secured token/secret, how are those requests authenticated by the OAuth API?
Intellectually, the best solution I could think of would to have some sort of token handoff between the Javascript client library and the API server via a HTTPS connection, in order to return a secret for the library to use. I'm not quite sure how I'd secure this handoff to prevent spoofs, though.
In most cases it is better to follow the standards than to implement some custom way. OAuth2 specifies 4 methods in the latest draft (28) to do the Authorization Grant flow. The implicit flow is the one you saw on Facebook.
As the standard says for that:
When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent.
Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application) since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, especially when the authorization code grant type is available.
it has some security drawbacks.
But as far as I can see, the other methods don't work for you, as they are exposing secrets to either the client (third-party website owner) or the resource owner (user), so you should stay with this.