I've implemented the oauth2-server which is awesome (but sometimes unclear) library. The problem is however, separate from oauth clients I also have users who just need to login. Do they do this with another grant then the authorization_code? If so which one?
Currently I'm doing this via my one-page application via a http POST request with username and password. Should i use the password grant for this? If so do I need to create an oauth client for my front-end application? (this just seems weird)
Basically, the oAuth authorization server supports 2 endpoints according to the spec: /authorize and /token. But if you need another capability, which is totally not related to the oAuth flow, you can add another API for that.
All other grants that you mentioned are related to different flows. The login support is not one of them.
So what I would do is add another HTTP API to support a simple login. This API get user and password (depends how you implemented your DB access - I assume that the passwords are stored in your DB encrypted, to your API should get an encrypted API as well, etc...)
BTW i have this GitHub repo https://github.com/OhadR/RESTful-login with a sample code how to perform (and use) restful login
Related
I have a background task that runs periodically which needs to connect to a customer's Apigee OAuth2 protected API. From my understanding of OAuth2, a user must go to a sign in page on Apigee, and it will redirect to a return Url with a token. This is the way I have used previously on website projects. But in this scenario, there are no users, no website, and no return Url, it is just some code making a http request.
Is the above possible to do? Every google search I make is all about users logging in manually and getting a token to a return url.
I found some mention of 'Flows' and maybe there is some other 'Flow'? but its really hard to get a clear understanding of how it works because guides are focused on user interactive websites.
OAUTH 2.0 is an industry-standard for authorization. OAUTH 2.0 supports many authorization grant types, namely they are;
Authorization Code
Implicit
Resource Owner Password Credentials
Client Credentials
[Note that you may come up with your own custom grants as well if you are building or extending your authorization server - however it is beyond the scope of this question]
In the example you have provided, you are using the Authorization code grant type where you redirect to APIGEE and getting an authorization code. The APIGE server acts as the "intermediary between the client and resource owner" in OAUTH 2.0 terms.
For your new requirement, you should consider using the client-credentials grant type where the client is provided a client key and a secret. The client has the responsibility of calling the authorization server (like APIGEE in your previous example or anything else) and getting a token and then using that token in the subsequent requests.
I recommend you to read the ietf standard for oauth 2.0 to get a better understanding - Refer https://www.rfc-editor.org/rfc/rfc6749.
Make sure to read on "Roles" in this link well before diving onto the content of this document.
Good luck!
I'm working in microservices environment, where each service authenticates using OpenID Connect to an authentication service (local IdP), based on Users I keep locally on my Database.
Now, I want these services to be able to authenticate using Azure, Google, etc.
Can (and should) I modify my authentication service to allow redirection to another IdP, and replace or chain the token to my proprietary token for my services?
Is there a simpler way?
How can I allow users to login both using name / password OR external IdP?
I'm doing some research on the topic by myself as well and from what I've found until now, it seems that there is a urn:ietf:params:oauth:grant-type:token-exchange grant type that should allow exchanging external idp token to an internal one as described in some spec.
It should be supported as part of the openid connect /token endpoint so as long as the local idp supports it, I guess that this should be the best practice to achieve what you are looking for.
I'm currently looking into mitreid-connect idp implementation as local idp and some of my requirements is to also allow SSO with third parties while being able to issue a local token from the external user identity.
Will update as it goes...
If you manage all the SP (your microservices) it's definitely easier to implement it on your common IDP.
But if the SP are external ones (like existing services you just installed) and they already implements the public IDP you want to use, it was be a bit harder to pass through your current IDP without problem.
I'm guessing you are in the first case (you made all your SP) so I will elaborate it:
When your current IDP will authenticate user on others public IDP, it will get some information (email, name, etc.) and you can normalize those in your answer, to be sure your SP are completely agnostic of which original IDP was used. It will be better for you if the future to debug this setup. And of course to add a new public IDP...
But if you need to use some specific call to original IDP, (let says Youtube API for example) you could have a agnostic API on your common IDP which will forward to the appropriate proprietary API of original IDP, or deny the request if the IDP does not have a video system.
Or you could give original token to your SP, in a custom field or scope of your oidc token, so for example an SP dedicated to video could directly call Youtube API with the google user token.
I recently did a similar setup for my company. I would like to share the overall structure to give an idea about our solution. Hope it helps:
Our authentication server is an node express server with following properties:
Hosts static login screens to allow authentication against local database via email + password, as well as provides links to authenticate with external OAuth2 providers.
Both local and external authentication requests are forwarded to Passport.js Authentication strategies
After successful login, both local and external Passport.js strategies respond to a callback. Upon this response, a session object is created via express-session and a cookie is sent.
At this point, cookies can be used to exchange JWT's, so that authentication against stateless API's can be possible with Bearer Access Tokens.
Does github (twitter, stripe & co) uses OAuth for its own signin/signup forms?
All those authentications are cookie based, so is this regular web client basic auth or does it use some form of OAuth or xAuth ?
On login, a call to https://github.com/session (or https://twitter.com/sessions or https://dashboard.stripe.com/ajax/sessions) is made (with credentials given as formdata) that result in a 302 (or 200 for stripe) with Set-Cookie and a location to https://github.com (or https://twitter.com).
It does not seems that they use a client_id to get a code and exchange it with a token. All the OAuth dance seems striped. And the Bearer header too. So, what's going on here?
Thanks.
OAuth is a three-legged system, two-legs is sort of useless. The whole point of using OAuth is to give other services the ability to perform actions as you without needing to specifically authenticate or pass the data yourself. In the end you must still authenticate against some Auth service.
Since you are using these services as the Authentication mechanism for other sites, it wouldn't make sense to attempt to use it in your own. As part of setting OAuth, the second site redirects to the first and asked to authenticate there, which means you literally need to enter your credentials. Which means that if you are okay entering your credentials into say github, having a different authentication mechanism is useless.
OAuth allows non-github to create user accounts by trusting github with the authentication, or it allows non-github sites to make changes to github as the user once the user agrees to the interaction by logging into github to accept that policy (logging in using their credentials).
Sign in forms on github (and others websites as well) are simply cookie based.
Usually every direct login via the website through a browser is made with cookie based system , simply because isn't necessary to do otherwise.
A bit of theory
Every time you use a login form in a website you are calling an API, not necessarily intended for public use (so a private API)
When you put your credentials in the login form and push that login button , your credentials are being managed by some code in the server that permits you to authenticate against that website.
There is no need for the entire OAuth overhead here because the website has full control on the authentication mechanism and isn't necessary to externalize.
Why OAuth is different in this contest?
OAuth is a system designed to distribute the authentication system across different services / applications even from different vendors.
In OAuth there are multiple actors involved:
the client
the authorization server
the resource provider
In your case all these 3 actors are the website itself and so there is no need for a decoupling system like OAuth.
I am currently being tasked with writing an RESTful API that we are going to release to our clients. I plan to use Web API 2 with OWIN middleware. The applications that will be accessing this can range anywhere from a Console app with no additional user authentication to full blow web applications that will involve user login and authentication.
One other requirement is that we need not only provide user authentication to control what data we will return, we also need to authenticate that the application accessing our API is allowed by our organization. So this requires us to not only validate the application invoking our API's but also the many users logging in via that application.
The goal is to use a bearer token technology like OAuth 2. I am not very familiar with OAuth 2 but after looking it over I don't see a way to facilitate a two part authentication like this. Ideally we would like to issue a clientId and a clientPassword and they would pass this in along with the userid and userpassword and we would then pass a token back.
Is this something that anyone has tackled before using OAuth2 or is this a job for a custom auth solution?
What you describe sounds like fairly standard Oauth2.0 scenarios so you shouldn't need anything custom.
For the web apps you could use the Resource Owners Password Credentials Grant. Which is a standard flow.
This allows your Oauth client to pass in its client Id and client secret along with a user's Id and password to your Auth Server which can then validate both the user and the client before issuing a token in response.
But I would recommend using the Authorization Code Grant which is probably the best option for web applications and it involves both the client and the user being effectively authenticated.
For you console apps, or any apps which are not user specific, you can use the Client Credentials Grant. This allows the app to authenticate and to get a token without a user.
If you need your API to be aware of the client application, the only flow you can't really use is the Implicit Grant which doesn't authenticate the client.
I am currently developing a web application that is right now comprised of a front end which displays and interacts with the data using a REST API we have written. The only thing that will ever use the API is our front end website, and at some point a mobile app that we will develop.
I have done a lot of reading about how OAuth is the ideal mechanism for securing an API and at this point I am starting to have a good understanding of how it works.
My question is -- since I am never granting access to my API to a third-party client, is OAuth really necessary? Is there any reason it is advantageous? Furthermore, because the back end is simply the API, there is no gateway for a user to authenticate from (like if you were writing an app using the Twitter API, when a user authenticates they would be directed to the Twitter page to grant to access then redirected back to the client).
I am not really sure which direction to go in. It seems like there must be some approach halfway between http authentication and OAuth that would be appropriate for this situation but I'm just not getting it.
From my point of view, one of the scenarios that favor OAuth over other options is to work with untrusted clients, no matter if these are developed by you or a third party.
What's an untrusted client? Think from the point of who handles the credentials that grant access to your API.
For example, your web application could interact with your API in two falvors:
Your web app server side talks to your API. Your web app server is a trusted client because the credentials to access your API can only be access by whom have access to the server...You and your team. You could authenticate your web app server with a client_id and a client_secret.
You may want to make calls directly to your API from your Web app client, which runs on the end user's browser using JavaScript. The end user's browser is an untrusted client. If you were to deliver the credentials to your API down to the browser, anyone could check the JavaScript code and steal your credentials.
A third party Native App is also untrusted. A malicious developer that uses your API could save the credentials of and end user of your platform.
Your Native App is a trusted client and could manage the authentication with a simple username , password and a client id identifying your App.
How can OAuth help? OAuth Authorization code and Implicit grants can help you with this issue. These flows only work with clients that support a redirect, like a browser. And let you authenticate an untrusted client and a user against your Authorization Server to gain access to your Resource Server, your API, without exposing the credentials. Take a look at the RFC to see how it is done.
The good thing of OAuth is that it not only supports these redirect based authentication flows, but it also supports client credentials grant and user credentials grant. So an OAuth Authorization Server would cover all cases.
OAuth 2.0 originally seems like a PITA if you think about having to build a lot of it yourself, but most languages have some really solid OAuth 2.0 setups which you can just bolt in with varying amounts of fiddling. If you're using a framework like Laravel or RoR then it's barely any work.
PHP: http://oauth2.thephpleague.com/
Ruby (Rails or Grape): https://github.com/doorkeeper-gem/doorkeeper
If you don't want to redirect users as suggested in your post then ignore other comments and answers that talk about two legged flows. You can use the client_credentials grant type to have apps just provide their client id and secret in return for an access token, which is nice and easy.
I would ask how private are we talking, because if the only systems talking to it are within the backend and have no interaction with the outside world you could probably leave it wide open and just rely on the network to keep it safe (VPN/Firewall).
But if it's private in the sense of "our iPhone app uses it" then you definitely want to go with OAuth 2.0, or something like it.
2 legged OAuth is probably what you want to use. It's basically hashing a shared key, but you have the advantage of not having to write the code yourself.
Here's a related question: Two-legged OAuth - looking for information
You should use Oauth for mobile device to API layer communication.
However, there is no benefit of Oauth in this web UI layer to middle-layer access (machine to machine).
On the other hand there are some potential issues
Managing the access token expiry becomes a pain. Consider that your UI has to cache the access token across multiple nodes in a cluster. Refresh it when expired, and the fact that UI layer is negotiating security with backend will just take extra time once in a while.
In two legged Oauth (OAuth Client Credential as in v2.0) does not support any encryption. So you still need to send key and secret both to the server for getting an access token.
Backend has to implement issuing access token, refresh token, validating access token etc, without any significant benefit