OAuth2 Data encryption

The OAuth 2.0 authorization framework allows a third-party application to gain limited access to an HTTP service, either on behalf of the resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to access it on its own behalf.

This means that you can allow certain users/apps to access your resources on a limited basis. Four of the components that interact in this deployment are:  

The Resource Owner: This is the owner of the resource keys, and this is where most clients come to get the credentials to access the resource. 

The Authorizer: After obtaining the resource owner's credentials, the client must obtain a bearer token that allows limited access to the resource. 

The Resource: This is what the client needs to encrypt and decrypt messages.  

The Client: A client does not always refer to a person in this context. Most of the time it refers to an application that tries to access resources and is also not specific to an application of type. It could range from a shell script to a web application. Here anyone can access the resource with the appropriate credentials. 

The customer requests authorization from the resource owner, if the acceptance criteria are met, the resource owner grants the authorization.

The client then needs to request the bear token needed to access the resource using the authorization grant obtained in the previous step.

The client can now access the protected resource using this bearer token for a limited time

Access request

All clients (applications) must register with the OAuth 2.0 authorization server from which they intend to request access tokens. When you register an application, you receive a key set. One is a public key called a client ID, and the other is a secret key called a client secret. Without these keys, an application cannot issue authorization code requests or access tokens to the authorization server.