The word Oauth stands for the open authorization, a standard protocol on which the information of each user is limited to other applications without providing a password. The OAUTH protocol allows applications to access users from a web service without the obligation to disclose their confidential information (such as passwords). In fact, when Oauth is enabled on an application (for example on the Gmail service), it provides an API where other applications can have limited access to your data. This mechanism is used by companies such as Amazon, Google, Facebook, Microsoft and Twitter to allow users to share and use information about their accounts with Third Party applications.
For example, you have an account on Gmail and you want to create an account in LinkedIn and have all your contact information there. One way is to register normally and add all the friends and those you are in contact with LinkedIn and another way is to use OAuth. With a license, LinkedIn will receive all your friends from Gmail.
Oauth 2.0
The Oauth protocol has two main versions of OAUTH 1.0 and OAUTH 2.0, each meeting different needs. We will talk about these two versions, history and comparison at the bottom of this course because our main purpose in this course is to review the OAUTH 2.0 protocol and then discuss it. Wherever the version is not mentioned, it means Oauth 2.0.
OAUTH function 2.0 in simple language
In this section, we want to give a simple and simple view of how the OAUTH 2.0 protocol works. The following figure shows a simple view of the structure of this protocol. This image represents 3 entities:
- User (User)
- The main program in which the user has registered (Authorization Server) like Google
- The sub -program where the user does not have an account and requires access to the user (Client).
If we look closely, it is clear that all components or entities are related, not one between the other.
OAUTH 2.0 Protocol Components
In OAUTH 2.0 four roles are defined:
- Resource Owner
- Resource Server
- Authorization Server
- Client
In addition to introducing these four roles, we want to get into the details a little and explain to you other components that we may name in the process.
Resource Owner
It is a user who has information and applications need permission from that user to access that information.
Resource
In fact, it is the information that is to be provided to the application with the permission of the user. Resource can include data such as (names, images, contact information, documents) and services (such as sending a blog, transferring money) or any other source of access.
Resource Server
The source server is a term in OAUTH 2.0 for the API server. The server hosting protected resources and is able to accept and respond to the request of protected resources using Access Tokens.
The source server manages valid requests after obtaining the Access Token. On a large scale there may be more than one source server. Google, for example, has dozens of resource servers such as Google Cloud, Google Maps, Google Drive, YouTube, Google+ and many others, each of which is completely separate, but all have the same license server set.
Authorization Serve
The server, or program, is issued an Access Token to the client after confirming the Resource Owner or user and obtaining a license from him. This server is responsible for identifying applications and issuing IDs or token for them to use user information. Needless to say, sometimes Resource Server and Authorization Server may be the same.
Authorization Grant
This phrase means granting a license and is essentially the same license that Authorization Server issued.
Client
It is an application that requests access and use of user information. In fact, the client is a program that wants to act on the user or access the user information. The client must obtain a license before access to the user’s account:
By directing the user to the Authorization Server, it receives the license.
It receives permission directly with Authorization Server without interacting with the user.
In the Oauth, two types of client are defined by different conditions and capabilities. These are the capabilities to determine authentication in Authorization Server.
- Confidential Client: Clients that are capable of maintaining their confidentiality (for example the client implemented on a secure server with limited access) or are able to authenticate the client securely using other methods.
- Public Client: Clients that cannot maintain their confidentiality (eg, clients used in the device used by the source owner or programs based on web browser) and capable of authenticating clients safely are not.
Based on the components introduced, the structure of the OAUTH 2.0 protocol and the diagram will be as follows:
Conclusion
In this section of the OAUTH 2.0 course, we are introduced to how this standard works in simple language. Follow us on this course to discuss this a little deeper and learn about the types of OAUTH authentication methods.