This blog post is part of a multi-part series:
Part 1 – Fundamentals of OAuth2, its roles and Grant types (this post)
Part 2 – Setting up a starter Project with REST API endpoints
Part 3 – Adding Spring Security and OAuth2 to protect REST API endpoints
Part 4 – Authenticating user against the credentials stored in the database
Part 5 – Persisting Client registration and auth tokens in the database
In this post we are going to learn:
- What OAuth2 is
- OAuth2 roles
- OAuth2’s Grant Types
- Password Grant Flow
What is OAuth2?
The OAuth 2.0 specification defines a delegation protocol that is useful for conveying authorization decisions (via a token) across a network of web-enabled applications and APIs. What this means is that it gives you a way to ensure that a specific user has permissions to do something.
OAuth 2.0 is not an authentication protocol and is not primarily used to identify a user.
Authentication versus Authorization:
A common misconception is that Authentication and Authorization are viewed as a single concept, but they are actually two distinct concepts. They are sometimes confused and interchanged.
Authentication is the process of validating whether a user (or system) is actually who they say they are. For example, an employee/visitor must show proof of identity in order to enter a secured building.
Authorization is the process of determining what actions you are allowed to perform once you have been authenticated. For example, once an employee/visitor is allowed in the secured building, he/she is given permission to access certain areas (floor/departments).
OAuth2 Roles:
OAuth 2.0 defines the following roles:
Resource owner (the User) – An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
Resource server (the API server) – The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client – An application making protected resource requests on behalf of the resource owner and with its authorization.
Authorization server – The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Grant types:
When a client application wants access to the resources of a resource owner hosted on a resource server, the client application must first obtain an authorization grant.
OAuth2 provides several authorization grants. Each grant type serves a different purpose and is used in a different way. Depending on what type of service you are building, you might need to use one or more of these grant types to make your application work.
The grant types defined are:
- Authorization Code
- Implicit
- Resource Owner Password Credentials
- Client Credentials
We will only focus on Resource Owner Password Credentials grant type because the sample application provided in this series is using the same type.
Resource Owner Password Credentials (Password) Grant:
OAuth2 provides a password grant type which can be used to exchange a username and password for an access token directly. Since this obviously requires the application to collect the user’s password, it must only be used by apps created by the service itself. For example, the native Twitter app could use this grant type to login on mobile or desktop apps. The user’s credentials are used only for a single request and are exchanged for an access token. This grant type eliminates the need for the OAuth2 client to store the resource owner’s credentials for future use.
If you have built your own OAuth2 service and created your own OAuth2 client application, you could use this grant type to authenticate users for your native Android, iPhone, and web apps.
Password Grant Flow:
The overall flow of Password Grant:
The client will ask the user for their authorization credentials (usually a username and password).
#1. Token Request:
The client requests an access token from the authorization server’s token endpoint by including the credentials received from the resource owner. When making the request, the client authenticates with the authorization server by providing client_id & secret.
#2. Token Response:
The authorization server authenticates the client and validates the resource owner credentials and, if valid, issues an access token.
Access and Refresh tokens:
Access tokens are credentials used to access protected resources. Refresh tokens are credentials used to obtain access tokens.
Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires.
#3. Resource Access:
The client accesses protected resources by presenting the access token to the resource server (API). The resource server must validate the access token and ensure that it has not expired and that its scope covers the requested resource.
#4. Resource Response:
The Resource Server provides the protected resources to the client based on the access token.
Conclusion
In this post, we learned the fundamentals of OAuth2, its roles, and Grant types. We also learned the flow of Password Grant in detail.
What’s Next in this series?
In the next part of this series, we will set up a starter Project and then dive into coding step by step to secure the REST API endpoints.
Share this post: on Twitter on Facebook on Google+