OAuth 2.0 is a standard to implement authorization with limited access over HTTP. We can use this add authentication to our REST API’s or can allow third parties to use your OAuth 2.0 server to authenticate users in their system.
For example, if you use a Google account to log in to Postman then you allow postman to get limited information about your account to have enough information to be signed up and log in. Postman can only access the information is authorized to use. It does not know your Google password.
In this series, we will learn how to create our own authentication so other systems can use our authentication server (in this case we are Google). This kind of authentication can also be used between our own (first party systems). For example, your mobile application wants to authenticate against your global authentication server that is also used to authenticate in multiple of your web applications.
Using OAuth 2.0 opens up a lot of possibilities for secure authentication of applications working with REST or Graph API’s.
League OAuth 2.0 server
If we want to implement an OAuth server in PHP. We don’t have to create one from scratch, we can use an external package like league/oauth2-server. This is, in my opinion, the best package you can find if you want to create your own OAuth 2.0 server.
The reason is simple, it allows you freedom in its implementation, allowing you to be in full control of its use and implementation. It is also not a specific Symfony bundle that is coupled to the framework or other bundles. It and can thus be implemented in any framework.
In this series of articles, we are not going to implement this package blindly. The goal is to implement this with the least coupling possible. Another goal is to keep it readable and understandable for anyone implementing it.
At the end of this series, you have an example of how to create an OAuth 2.0 server in Symfony and the knowledge to tailor it to your needs.
Terminology
Before we can continue it’s important to understand the terminology of some of the OAuth 2.0 terms.
You should have a clear understanding of the roles in an OAuth 2.0 server, what an access token is and the basic idea of Grants. Later in the series, we will dive deeper into these terminologies.
Roles
OAuth defines 4 roles. Resource Owner, Client, Resource Server and the Authorization Server. All of these are different ‘entities’ in the OAuth 2.0 authorization flow.
First, you have the Resource owner. This is the user (person logging in) who is authorizing an application access to their account. The application has limited access to the Scope of the authorization that is granted. It can only see the users details it has been allowed to see.
The Client is the application that wants to access protected resources on behalf of the Resource owner. This can be User information or accessing resources that are behind a REST API. The amount of access this client has is determined by the Scope it is allowed to access.
The Resource server is the server or API which can be used to access the user’s protected resources. This can be any user based information that is behind your custom API. The Resource servers task is thus to accept and respond to protected resource requests by using Access tokens.
Then last but not least, we have the Authorization server. This is the server that issues the Access tokens after the Resource owner and Client is successfully authenticated.
Access token and JWT
An access token is a token used to access protected resources. This token is the key to the resources of a resource owner and client. Most of the time this is a JWT which stands for JSON Web Tokens. This JWT is an open and industry standard and method to securely use tokens between 2 parties. The client and the authorization server in our case.
This standard allows us to have secrecy between the authorization server and client by encrypting and signing the tokens. We can then sign this token with a private/public key combination and verify that we are authorizing against the correct authorization server.
In short, a JWT token is a secure way to work with OAuth 2.0 tokens on a javascript-driven web. These tokens can be saved on the client (PHP server or web client) without leaking any crucial information like passwords. These tokens also have a limited time life. They need to be refreshed from time to time.
Grants
A grant is a method to acquire access tokens through the Authorization server. Later in this series, we will have a dedicated article going over all the possible grants and when to use them.
For now, we will be using the Password Grant as an example through the first parts of this series. This is the most common one and is used to authenticate users through a username and password.
Another one that is also used very frequently is the Authorization Code grant which is used when signing in using Facebook or with a Google account. The authorization happens with a code instead of a username and password in this case. But more on that later.
Before we continue we also need to talk about the Refresh token grant. Access tokens expire. And we have a special grant for refreshing these tokens without needing to go through the whole authentication flow again.
A quick summary
As you can see this is all connected to each other. The resource owner (user) is authenticated against a client. The client then wants to access the resource server, but first, needs an access token from the authorization server. This can only happen if it authenticates using a grant against the authorization server by providing the correct authentication information of the resource owner and client (application).
There is a distinction with what application you are authenticating on. Because maybe your mobile application has more limited access to information then your web apps. These clients can also be multiple third-party applications with different kinds of access to resources.
The Next Steps
Now that we got a basic overview of what OAuth 2.0 is and that we are going to create an OAuth 2.0 server setup in Symfony. This by applying the ideas behind layered architectures and clean code. Making sure it is as decoupled as possible.
We are going over all the steps from beginning to end and also explaining the reasoning and ideas behind the choices we make.
I hope that this will give you a very in-depth picture of OAuth 2.0 and will allow you to customize this solution along the way for your use cases. Helping you to make the right choices, and maybe giving some feedback back to me about how you look at some of the choices I made in this project.
Next week we will create the basic Symfony project setup, explain the plan and set up the Symfony security component with a User Provider to be ready to start the actual implementation of the server.
This will be a long series covering multiple weeks. But I hope you will enjoy the ride.