With the advent of a large number of web services, it became necessary to provide resources from one service to another. The very first implemented solution was for the user to provide a login and password to service A so that it could receive data from service B. However, this solution has the following number of problems and limitations:

• Service A needs to store the username and password on its own; moreover, the password is stored unencrypted.
• You cannot select a subset of resources, and also limit the time of their availability.
• The user cannot selectively deny the service access to its resources. If you change your login or password, all services will lose access.
• Hacking one of the services will lead to leakage of the user’s login and password, and, therefore, access to the private data of another service.

Thus, to solve the problems indicated above, the OAuth specification was proposed, by implementing which it becomes possible for a third-party service to securely obtain limited access to the resources of another.

NoteThe article is of a purely informative nature, and does not pursue the goal of presenting the material on the topic in as much detail as possible - there is documentation for this. It should be mentioned that the article appeared due to the study of this issue by the author himself. If you do not know what OAuth is, then below is the material that I tried to summarize and present in an accessible form.

There are two versions of the specification: OAuth 1.0 and OAuth 2.0 , which, by the way, are backward incompatible. The first version was published in 2007, and is a document with recommendations for delegating resources to a third-party service without disclosing the username and password, while the second version (2012) is already an Internet standard, takes into account the shortcomings of the first version, and expands possible scenarios usage (selective access to resources, 4 types of authorization, use of native applications, refresh token, etc.). When they talk about OAuth, they usually mean the second version, since it is most often used, and we will talk about it in more detail below.

Characters

The OAuth 2.0 specification distinguishes the following roles:

• Client. A service (application) that wants to access user data.
• Resource Server. Service that owns user data.
• Authorization Server. A service that provides the user with an interface for choosing whether or not to give access to the resources of a third-party service.
• Resource Owner. The user who gives access to resources.

Let’s consider the work of OAuth from the point of view of the Client as with the most frequent use case for developers, and the details of the implementation of the Authorization Server are already documented.

#статьи #api #golang