Introducing
There are different "paths" to "connect" with Oauth2 and recover
an access_token you will need to consume your API. Whatever
the way you use to recover the access_token, you will
get something like this:
{
access_token: "NGM3NDI2OGQ0MTRjMjhkYzY5ZGQ1YjViODhmYzNlZmRiNGI3YjIxN2IxZDcxY2ZjMDI3MmY3NjI2N2ZhODJjYQ"
expires_in: 3600
token_type: "bearer"
scope: null
refresh_token: "MjQyNTM0NjBiMmZlYjY3MGM2OGJmMDllZjE0ZjNhYTMxZmIyN2ZmMGRlOGJlOGUwYjRkZmJkMWU4NmY5NDVlYQ"
}
We will present the ways grant_type can be used
important to know that you can define in your client a
or more types of grant_type to perform the authentication, the examples
which will be cited are specific to Fosoauthserverbundle:
We have the following situation
Let’s imagine two Symfony projects :
A back-end with API and database (Fosrestbundle and Fosoauthserverbundle with Fosuserbundle),
And a API-consuming front end (Hwioauthbundle, no database), which will one day be replaced by a JS implementation.
authorization_code
If the goal is to connect to the front end with a Facebook-like login process, in this case the authentication process should be the authorization_code.
grant_type=authorization_code
In this environment, the front-end is an oauth_client that tries to connect to
back-end.
You must create an oauth_client in the back end in order to be able to perform the authentication. You will need the public_id and secret of the client created.
Heed: If you are searching the public_id in the database, you should keep in mind that it is the id of oauth_client.id concatenated with oauth_client.random_id separated by an underscore. Something like:
1_kj2gjhlice8wkoxwggpok80hk0wcewkwfkk4c4wocawwgc0ko
Understanding the process (authorization_code)
The "normal" process you have with Facebook : login, application authorization and redirection. In this environment a user will login to your server through the front end. This would be the process:
- The front-end must redirect to an endpoint implemented in the back-end that will display the login form, with its oauth_client id.
- The user will fill in the form and send, and if valid, by allowing the application "app" (which is oauth_client, implemented in front-end) access to the back-end.
- The user is redirected to the front-end, with a new cookie (access_token) that allows the front-end to recover data via the back-end API.
password
You want to carry out for the server through its own form implemented in the front end the credentials of the client and the user who is trying to perform the authentication, without callback steps where there are the redirects.
This process is not as secure as the original implemented by
"Facebook/Google/Github".
grant_type=password
You will get the back-end access_token, but it will be obtained through a single request (no redirection required), in this method you will send both the data to authenticate the application : oauth_client id and secret, and the user data.
your_back/oauth/v2/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=password&username=USERNAME&password=PASSWORD
This process is simpler, but your front-end is storing the secret client. It is necessary to evaluate the security issue, you may not have many problems if your front-end is PHP or other language where this authentication information is not visible to the client, but if your front-end language is Javascript for example, in that case, it might not be a good idea.
client_credentials
In this situation you will implement the levels of direct access in the client and in this case you will not need the permissions of the user, because the "roles" of the client that will restrict your access.
grant_type=client_credentials
Simple request, user data is not sent, you send only the data to authenticate the application oauth_client id and secret :
your_back/oauth/v2/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=client_credentials
This can be useful when your back-end is a request
of your API, where user credentials are not required.
refresh_token
This will be useful whenever your access_token expires and you need to update so that you continue to perform the requests without the need to redo the entire authentication process.
grant_type=refresh_token
This is to get a new valid token (which has not yet expired) access_token. As your token will expire in an hour (this value can be modified), you can ask the back-end to update :
your_back/oauth/v2/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
authorization_code
grant_type=authorization_code
The authorization code is obtained through a server of
authorization as an intermediary between the front end and the
back-end. Instead of requesting authorization directly from the front-end
, the front end redirects the user to an authorization server, which in turn redirects the client back to the front end with the authorization code.
The authorization server authenticates the
user and generates the authorization. The client only authenticates with the authorization, the user credentials are never shared between the front-end and back-end.
The authorization code provides some security benefits
important, such as the ability to authenticate the user, as well as
the transmission of the access token directly to the front end without exposing the user
Original article:
https://gist.github.com/lologhi/7b6e475a2c03df48bcdd