On the other hand, the client might be another web service, and in this case the user will be redirected to the authorization server with the client id, optional scope parameter and redirection URI by the client so that the user can authenticate itself. A appropriate real-life example is Facebook integration on Twitter. Twitter, the client, needs access on protected resources to post your recent tweets on your Facebook timeline. After a successful authentication, the request will be redirected to the clients redirection URI with an authorization code, with which the client can request an access token from authorisation server. In this “authorization code” grant, the client access to the user credentials is not permitted.
Scope defines the boundaries of the authorization. The authorisation server might allow the clients to specify the scope for the access requests with the scope parameter in which scope the access token should be effective. RFC 6749 3.3
Scopes are optional in workflows.
So far, I have covered some essential topics of the OAuth 2.0, that we need to understand to build our enterprise authorization backend. But, there is more. If you are interested in OAuth 2.0 I encourage you to read the RFC 6749. It is in my opinion the most concise document describing the workflows.
Next step, we are going to start building our backend components like Authorization Server, Resource Server, etc. to implement OAuth 2.0 spec and to grant access to our protected resources. The resources are sample REST resources just giving out some important information like “Hello World”, that we want to protect.
I am going to set up a docker container environment to start the whole back-end on my local computer while developing the components. To work with docker container environment will accelerate our development and test cycle and later on once we decide to deploy our back-end much more easier to roll it out onto a container orchestration platform like Mesos or Kubernetes.
First things first and we need is a database to store the user data like username, password, etc. For this purpose, I will use a MySQL Database with the following schema:
Just keep in mind this SQL schema. After starting the database, we will revisit and apply it with your favourite mySQL client to the database and create the table above.
To build our backend, we will start off with a Maven project and inherit our Maven POM from Spring Boot parent, that is very convenient and ensures that the right versions of Spring dependencies will be added to the project. For the sake of ease, I will create a single project which include both the resource and the authorization server in the same application, but in production, you may want to split them into two separate services.
We will also need the following dependencies to enable the Spring Framework in the project:
As you may have noticed, the project defines some database dependencies, as well, in addition to those which are required for the OAuth. The idea is basically to keep the user data in a database table. Alternatively, we could store the user data in a in-memory database, this is provided by the Spring Framework.
The first component we create is the authorization server. I will create all components in a single Spring Boot project for the sake of ease. In a real-life application, you need probably consider to create separate applications for the authorization and resource server.
In this update, we now know how to create the foundation and start the components by spinning up the containers by using docker-compose. I am continuously updating the article and certainly will someday be complete. Just stay tuned!