In this video we will create our first OAuth2
We will see what details we need to create our
Client, what properties will be automatically generated for us, and how we can then use this
Client's credentials to gain an OAuth2
At this stage, we will be doing the whole process manually.
Needless to say, at this stage we are in development and enabling TLS is a little extreme, but if you are putting this system in to production, at least TLS 1.0 is expected to be in place.
As such, the first thing we need to do is create a
Client. We're going to achieve this by using Doctrine's Data Fixtures, although there really isn't a great deal of configuration required to create a valid client.
Firstly, we need to give our client one or more
Redirect URIs. We are only giving one, but you can give as many as you like.
Any given Redirection URI must be an absolute URI - in other words,
http://www.yoursite.com/redirect.php is fine, but just
/redirect.php is not.
As we will see later, you won't always need the
Redirect URI, it depends on the
Grant Type you are implementing.
Grant Type describes the workflow that a
Client goes through to get an
There are four
Grant Types defined in RFC6749:
There is another Grant Type called the Refresh Token grant, which we will also cover. This is defined in the RFC, but isn't one of the core four defined grants.
You can also implement a custom
Grant Type if the above choices don't meet your requirements.
Implicit grant type is designed for public
Clients where the
Redirect URI is known and trusted.
This flow is fairly simple, we only need to pass three pieces of data to the
auth end-point and, all things being well, we will receive an
Access Token in the response. These are:
If all goes well, you will get an Access Token as part of the URL you are redirected too.
This flow is hotly debated as being insecure.
This is the
client_credentials grant type.
This is the easiest flow to see in action.
To gain an
Access Token we simply need to pass in a valid
Client ID and
As you will see in the video, these values will be created for us when a new
Client entity is created.
We pass in the
client_secret, and use a grant type of
client_credentials, and if all is valid, in return we will receive an
This flow is useful for accessing protected resources that this Client controls.
As you are exposing the
client_secret, there must be a strong degree of trust between
Client and the server. An example of this may be when you have a script on the same server as your OAuth2 API that consumes your API, and you wish to call that script using a cron job.
Remember - this is the credentials of the
Client, not the User account of the person trying to use this flow.
This is the
password grant type.
With this grant type, the Client will require the end-user to provide their Username and Password as part of the process of being able to generate their
We need all the same pieces of data that the Client Credentials grant type used, along with a valid
Security is beyond important here. It's critical. If you mess up the security on your implementation here, user names, passwords, Client data, the works... it's all out there.
This is the kind of grant type you would likely use for you or your companies internal mobile Client.
This is perhaps the most commonly thought about variety of OAuth2 log in flows.
You can think about yourself as being like Facebook, Google, or Github. Others trust you enough to use your user base as a validator of others.
If you're not Google, Twitter, or some other behemoth - in my opinion - this one is less valuable to you than the others.
That said, the flow here is easy enough to follow. There is just an extra step in there that is likely unnecessary in most small to medium-sized business situations.
If you have found this video helpful, please consider sharing. I really appreciate it.
|1||Installing FOS User Bundle - That is not a typo!||07:52|
|2||4 Key OAuth2 Terms You Need To Know||06:46|
|3||Creating and Using Our First OAuth2 Client||05:41|
|4||How Our OAuth2 Tokens Are Created||06:58|
|5||Client Credentials and Password Grant Types||07:43|
|6||Authorization Code Grant Type||04:17|
|8||Scope and FOSOAuthServerBundle||08:12|