OAuth2 With In-Memory and PostgreSQL Database Example, Part 1

nowadays, security is very important for everywhere like working with small and huge applications, live projects, banks, small and huge companies, schools, etc...

i will go through and discuss security in small applications and live projects in this article.

today, i am going to explain the oauth 2 life cycle with a framework as per my understanding. i will explain the basics of oauth 2 with the example of a spring boot crud operation with in-memory and a postgres sql database.

contents:

1. overview of oauth 2
• introduction to oauth2 authentication
• why use oauth2?
• oauth2 architecture
• advantages and disadvantages of oauth2
2. oauth2 roles
3. abstract protocol flow
4. application registration
5. authorization grant
6. oauth2 client types
7. oauth2 client credentials with endpoints
8. oauth2 requests and responses
• authorization code grant requests and responses
• implicit grant requests and responses
• resource owner password credential grant requests and responses
• client credential grant requests and responses

now let's start discussing the oauth2 framework in depth.

1) overview of oauth2 authentication

introduction to oauth2

oauth2 is an open authentication and authorization protocol which enables us to access data from another application. it works by accessing user authentication to service the app that host's the user account and authorizes third-party applications to access the user account.

oauth 2 was developing by the ietf ( internet engineering task force ) oauth working group and was published in october 2012.

why use oauth2?

oauth2 allows the user to read data from one application while working in another application. oauth2 provides an authorization flow for web, desktop, and mobile applications. oauth2 is a server-side web application that uses authorization codes and does not interact with user credentials.

it allows us to access user resources without sharing passwords.

advantages of oauth2

• it is a flexible protocol that relies on ssl to save user access tokens.

• it is useful for cryptography protocols.

• it is used to keep user data safe on ssl.

• it allows limited access to user data and allows the user to access their data, even when authorization tokens have expired.

• it gives the user the power to share their data without having to release personal information.

• it is easier to implement and develop small and large applications.

• it provides strong authentication and authorization.

disadvantages of oauth2

• users can be tracked easily.

• if your site or application is connected to a central hub, and that central hub account is hacked, this could lead to serious effects across several sites instead of just one.

2) oauth2 roles

oauth defines the following roles for users and applications:

• resource owner
• client application
• resource server
• authentication server

resource owner

the resource owner is the user who authorizes the application to access their account. the application's access to a user's account is limited to the scope of authorization granted, i.e. read and write access. thus, the resource owner is an entity capable of granting access to a protected resource. when the resource owner is a person, they are called the end-user.

client application

the client is an application which requests resources to perform an action on behalf of the resource owner, thus the client application is the entity that wants to access a user's account. before clients do something, it must be authorized by the user and the authorization must be validated by the api. clients can be an application, a user, a mobile device, etc.

resource server

the resource server is an api server that can be used to access the user's information. it has the power of accepting and responding to resource requests with the help of access tokens.

authentication server

the authentication server is the server for authorizing the client application to access data or resources that belong to the resource owner. it gets permission from the resource owner and distributes the access token to the client to access the resource that is hosted by the resource server.

3) abstract protocol flow

now, let's see discuss how the above roles interact with each other.

here is a more detailed explanation of the steps in the diagram:

1. the client application requests access to the service/resource from the resource owner. the authorization request can be made directly to the user or indirectly via the authentication server as an intermediary.
2. if the user authorized the request, a client application receives an authorization grant.
3. the client application requests an access token from the authentication server by presenting authentication of its identity and the authorization grant.
4. the authentication server receives a request for the access token of the client. after receiving the request, the authentication server authenticates the client and validates their identity. if authentication is granted and the client is valid, then the authentication server sends an access token to the client application. authorization is then complete.
5. after receiving an access token from the authentication server, the application requests the resource from the resource server and presents the access token for authentication.
6. resource servers receive the access token and verify whether the token is valid or not. if the token is valid, then the resource server serves the resource or data to the client.

4) application registration

before your application uses oauth, you must register your application with the service. after opening oauth's website, go to the developer or api portion of the site. here, you give information about your application like:

• application name
• application website
• redirect url or call back url

the redirect url represents the service that will redirect the user after they authorize or deny your application and, therefore, the part of your application that will handle authorization codes or access tokens. once your application is registered, the service will send client credentials in the form of a client identifier and client secret .

the client id is a string that is used by service apis to identify your application and to authorize urls that are represented to users.

the client secret is used to authenticate the identity of your application to the service api when the application requests access to a user's account and must be kept private between the application and the api.

5) authorization grant

the authorization grant is given to a client application by the resource owner, in cooperation with the authentication server associated with the resource server. oauth2 gives four different types of authorization grants. each type has different security characteristics. the authorization grant types are:

• authorization code: used with server-side applications.
• implicit : used with mobile and web applications.
• resource owner password credentials : used with trusted applications.
• client credentials : used with applications' api access.

now we will describe grant types in more detail and their use cases and flows, in the following sections.

authorization code

i will explain the authorization code block via a diagram and step-by-step information, which is mentioned in the diagram, which shows the role of the authorization code in oauth2. now let's start to discuss the authorization code:

1. the resource owner (user) sends a request to access the client application.
2. the client application gives a response to the user to login to the client application via the authorization server.
3. after receiving a login request from the client application, the resource owner (user) sends a login request via the authorization server.
4. the authorization server sends a request for the client id and client secret back to the user via a redirected uri and oauth code. this way, the authorization server easily knows which resource is accessed by the user based on the client id.
5. the resource owner receives a redirected uri and sends the client id and client secret to the client application.
6. the client application gets the client id and secret and sends it to the authorization server.
7. the authorization server validates the client id and secret to check whether or not it is valid. if it is valid, then the authorization server generates an access token and sends it to the client application.
8. after receiving an access token, the client application sends a success message to the resource owner.
9. now successfully logged in, the resource owner accesses the client application and sends a request to get more data/details/resources from the client application.
10. the client application can now use the access token to request resources from the resource server. the access token serves as the authenticator of the client and resource owner (user) and provides authorization to access the resources.
11. the resource server receives a request and access token from the client application. after sending any data/details/resources, the resource server verifies the access token and sends it to the authorization server to check whether or not the access token is valid. after receiving a valid response back from the authorization server, the resource server returns the data/details/resources which the client requested.
12. the client application receives a response from the resource server and shows the resources to the user.
13. now the user can see the resources from the client application.

implicit authorization grant

an implicit authorization grant is similar to an authorization code grant, except the access token is returned to the client application after the user has finished the authorization. the access token is thus returned when the user agent is redirected to the redirect uri.

this, of course, means that the access token is accessible to the user agent, or native application participating in the implicit authorization grant. the access token is not stored securely on a web server.

furthermore, the client application can only send its client id to the authorization server. if the client were to send its client secret as well, then the client secret would have to be stored in the user agent or native application too.

implicit authorization grant is mostly used in a user agent or native client application. the user agent or native application receives the access token from the authorization server.

here is a diagram showing how implicit authorization grants work, which describes the workflow of said authorization process:

resource owner password credentials

the resource owner password credential authorization grants method works by giving the client application access to user credentials. with the resource owner's password credentials grant type, the user provides their service credentials (username and password) directly to the application, which uses the credentials to obtain an access token from the service.

this grant type should only be enabled on the authorization server.

using the resource owner password credentials requires a lot of trust in the client application. you do not want to type your credentials into an application you suspect might abuse it.

the resource owner password credentials would normally be used by user agent client applications or native client applications.

password credential flow:

after the user gives their credentials to the application, the application will then request an access token from the authorization server. the post request might look something like this:

https://oauth.example.com/token?grant_type=password&username=username&password=password&client_id=client_id

if the user credentials check out, the authorization server returns an access token to the application. now the application is authorized.

client credential authorization grant

the client credential authorization is for the situations where the client application needs to access resources or call functions in the resource server, which are not related to a specific resource owner (user).

client credentials flow

the application requests an access token by sending its credentials, its client id, and client secret, to the authorization server. an example post request might look like the following:

https://oauth.example.com/token?grant_type=password&username=client_credential&client_secret=client_secret&client_id=client_id

if the application credentials check out, the authorization server returns an access token to the application. now the application is authorized to use its own account.

tune back in tomorrow when we'll go over client types, endpoints, and requests and responses!