We have a situation here
We will imagine two Symfony projects :
As our users will try to connect to our front, we want a login process à la Facebook, which you will see, is the oAuth
The front is an
oauth_client who try to connect to the back.
oauth_client is created with a command line on the back. You then retrieve an
id and a
Warning If you look into the database to get the
You need to learn a bit of oAuth2
id, it's the concatenation of the
oauth_client.random_id, separated with an underscore. Something looking like
You need to understand that there are different "ways" to "connect" with oAuth2 and retrieve an
access_token that you will use to hit your API. They are well explained in this Tankist blog post (read them all, they are just great).
Whatever the way you use to retrieve the
access_token, you want to get something like this :
These ways are defined by a
grant_type that you set to an
grant_type is possible) (it might be specific to FOSOAuthServerBundle, but I presume you will not use something else) :
The "usual" process you have with Facebook : login, authorize app, redirection. So the user want to connect to your front. Simplified, here is what's happening :
- The front try to get the login form from the back, with its
- The user put its credentials in the form, and if it's valid, can allow the "app" (which is the
oauth_client, i.e. the front) to access the back.
- The user is then redirected to the front, with a nice cookie (
access_token) that allow the front to request the back API.
No example here, we will come back on that process later.
You still want an
access_token but you get it in one request, by sending everything you have :
secret, and user credentials.
The process is of course simpler, but your front is storing the
Simplest request, no user credential, you only send
This might be usefull when your back is requesting another of your API. User credential might not be needed.
This one is to refresh your
access_token. As your token will expire in one hour, you can ask to refresh it :
As you need to have the
secret, this is not usable between our front and back, where
grant_type=authorization_code will be used.
I found it was the clearest explanation of the authorization_code :
The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server, which in turn directs the resource owner back to the client with the authorization code.
Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client.
The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner.