Creating and Using Our First OAuth2 Client
In this video we will create our first OAuth2 Client.
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 Access Token.
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.
Redirect URI
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.
Allowed Grant Types
A Grant Type describes the workflow that a Client goes through to get an Access Token
There are four Grant Types defined in RFC6749:
- Implicit
- Client Credentials
- Resource Owner Password Credentials
- Authorisation Code
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
The Implicit grant type is designed for public Clients where the Redirect URI is known and trusted.
An example of this, according to the RFC, may be a browser app coded in JavaScript.
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:
client_idredirect_uriresponse_type
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.
The only apparent use-case for this grant type would be where a browser-based application has been written using JavaScript and has no server / back-end requirement. Any other scenario would result in an insecure implementation.
Further Reading
- What is the purpose of the implicit grant authorization type in OAuth 2?
- OAuthLib Documentation (ignore the non-issuance of Refresh Tokens notice)
- OAuth 2.0 Server - League of Extraordinary Packages Implementation
- RFC6749 - Section 1.3.2 - Implicit Grant Type
Client Credentials
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 Client Secret.
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_id, client_secret, and use a grant type of client_credentials, and if all is valid, in return we will receive an Access Token.
This flow is useful for accessing protected resources that this Client controls.
As you are exposing the client_id and 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.
Further Reading
- OAuthLib Documentation
- OAuth 2.0 Server - League of Extraordinary Packages Implementation
- RFC6749 - Section 1.3.4 - Client Credentials Grant Type
Resource Owner Password Credentials
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 Access Token.
We need all the same pieces of data that the Client Credentials grant type used, along with a valid username and password.
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.
Further Reading
- OAuthLib Documentation
- OAuth 2.0 Server - League of Extraordinary Packages Implementation
- RFC6749 - Section 1.3.3 - Resource Owner Password Credentials
Authorisation Code
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.
