I have built my own REST API with Symfony2. To query this API, user have to authenticate himself with OAuth protocol (three legs flow).
Now, I'm going to develop the front office based on a Angularjs app and I want to use my own Rest API from angularjs. What's the best way to login users to my api from the front office and fetch a token ?
I dont want users have to authorize my own app.
Does the three legs flow is really adapted for this case ? Maybe is better to support xauth authentication with a username/password login ?
Ok after some research, it seems that the most easy way to manage login/authentication between JS client and Symfony2 backend is to use password grant type (thanks #ricoux) which allows user to get a token with an username/password, like this:
http://host.com/oauth/v2/token?grant_type=password&username=Bat&password=test&client_id=clientidkey&client_secret=clientsecretkey
With fosoauthserverbundle, you need to set allowed grant type when you create your client:
$clientManager = $this->container->get('fos_oauth_server.client_manager.default');
$client = $clientManager->createClient();
$client->setName('ApiTest');
$client->setRedirectUris(array('URL' => 'http://callbackurl.com'));
$client->setAllowedGrantTypes(array('token', 'authorization_code', 'password'));
I try to do exactly the same thing : REST API with symfony2 and a javascript client with angularjs...
As Nisam said, FOSOAuthServerBundle is the best bundle to integrate OAuth2 authorization server in your symfony2 app.
I your case, if you don't want users have to authorise your own app, maybe a client with password grant type is the solution. In theory the password grant type can be used to exchange a username and password for an access token directly, but I never experiment it with FOSUserBundle, and I find no example in the doc.
When you ready to use third party bundles, FOSOAuthServerBundle is one of the best solution
Related
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
I am playing with JWT and expressJS to learn something new, and come up with the idea to make my little JWT provider to use for all my future personal projects.
The idea is quite simple, my provider will register with facebook and twitter API, and will use passport to authenticate with them. I will also store users credentials so I don't need to worry about that in my other projects (these project will hold their info about users but various data from socials/passwords etc.. will be in the provider).
I coded this little workflow:
I register the app in my provider with a callback url
Put a button (e.g. 'Login with Twitter') on my project, that links directly to my provider
when I accept the Twitter conditions, twitter callback calls my provider that pick the right user and redirect to my project.
I am stuck on this last point, I would love to pass to my project the JWT token to use for its next requests, but how do I pass to it?
Cannot set cookie because domains are different obviously, I am missing something? Did I follow the wrong way?
The authentication flow you describe is similar to OAuth2. I suggest to read the RFC 6749. It explain the technical details to implement it. You can also refer to OpenID Connect. It is an extension of OAuth2 using JWT
Basically you need to create an access token after a successful login and return a redirection to the callback url. The adapted flow to your context could be the following
App redirects user to central login form
The server prompts user for the credentials :It returns an HTML form with the supported authentication methods, that can include a connection with a third party authentication provider
After a successful authentication, the server creates an access token. It can be a JWT
The server returns a redirection to the provided callback url. It includes an authentication code
The app request the authentication server using the previous code and get an access token
The token can be used by app to access to a protected resource
In Oauth2, the access token it is just a random string, but you can use JWT perfectly.
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.
Currently, I'm working on a REST API which will be available for public clients but also I wanted to use it in my mobile application.
For the public clients, I considered to use the Clients Credentials grant, in this case, they would have to registered their app in my Web application which will give them the client key and client secret, then, they could request the access token with them and also I could know the user related to the credentials
But with my mobile application, I'll need to have a sign in section where I would need to use Authorization Code grant in order to secure my data, but I'm not sure if it's necessary.
Based on this, I have a couple of questions:
1. The Authorization Code grant it's the best way to do it?
2. It's a bad practice to have two authorization flows in the same endpoint?
3. Dropbox, Twitter, etc...all of them have REST API, how do they manage authorization in their own apps?
Thanks beforehand and sorry for all questions
I managed to solve this with two alternatives and for the moment, I'm going with the first one.
Create an Authorization server with a parameter that indicates what kind of Authorization Grant it's asking to use and in this way I can decide which kind of flow will follow based on this. I follow the OAuth 2.0 Spec for this using the correct names and parameters to pass in order to have a good way to authenticate our clients and applications.
Create an API gateway where I can send all the authentication requests for my API's using Node.js and in there it will be decided which API it's asking for authentication and with kind of Authorization Grant it's using. You can have more information about this in here:
https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
I'm gonna try to explain my problem :
I'd like to allow users to connect to my api via their own accounts (login/password) or via a social network (Facebook at first).
Then, I would allow any application to use my api, with the user authenticated.
My first thought when to auth the user via his/her login/password and return a token used as the session for the next requests.
But OAuth would seems to be the better implementations, except I don't know how to do this :
One of my applications will have to connect via login/password, like twitter web (I have to implement an login/password auth somewhere if I wan't my user to login :p)
Will I also have to register my applications to the oauth system (did twitter added their web app to their oauth ?)
How to merge the auth via others social networks. Concretely, the user will have to OAuth to my api that will auth to the social network.
I'm a bit lost on how to do this, if someone could help me, I would really appreciate !
Thanks
Update 1:
Flickr and Lastfm seems to not use OAuth but an alternative auth system that looks like this :
The user is redirected to Flickr/Lastfm
The user auth himself and accept to use the application
Flickr/Lastfm return to the Callback url with a temporary frob (for flickr) or token (for lastfm)
The app must call the provider with the temporary frob/token (among with the api_key and the api_sig, as always) and get in return the session token to use for the next calls.
Update 2:
In fact, StackApps is the concrete case of my problem : you can login through their login/password system OR openId, and you can use their API.
OAuth is only needed to make others use your API on other services, i.e. authorize services to use your API without users of the intermediary service explicitly having to log in into your service by giving user's login credentials to a third party.
What I think you need is OpenID, the cross-application authentication mechanism. You just need to implement an OpenID client, accepting third-party OpenIDs to authenticate users, to subsequently identify them, when they use your service's API. This would have to be supplemented with a normal 'local' user authentication mechanism (i.e. login/password entry page)
You will need OAuth to provide an ability to use your API on other sites, though.