Baidu Encyclopedia defines an open platform as follows:
Open Platform In the software industry and network , an open platform refers to a software system that enables external programs to increase the functions of the software system or use the software by exposing its application programming interface (API) or function (function). system resources without changing the source code of the software system .
In the Internet era, the service of a website is encapsulated into a series of computer-friendly data interfaces and opened for use by third-party developers. This behavior is called Open API, and the platform that provides open API itself is called an open platform. Through an open platform, websites can not only provide simple access to Web pages , but also perform complex data interactions, transforming their Web sites into development platforms equivalent to operating systems. Third-party developers can develop various applications based on these existing and public Web sites. Secondly, the open platform contains a variety of meanings. I will not repeat them one by one. The author mainly focuses on the process from the first time the author participated in the development of the open platform to the first online version. Please make up your own brain for other related theoretical knowledge.
The demand I received is: use the oauth2.0 protocol to complete the construction of an open platform, like WeChat.
So what is the oauth2.0 protocol?
1. OAuth (Open Authorization) defines a safe, open and simple standard for the authorization of user resources. The third party can obtain the user's authorization information without knowing the user's account number and password, and this is safe. of.
2. OAuth2.0 is the latest version of OAuth
3、https://oauth.net/2/
With a smear of eyes, it was introduced at the company's internal technology sharing meeting, but at that time, there was no corresponding time to research and ponder, resulting in wasting most of the time in learning the oauth2.0 protocol, which is really inappropriate.
To say that bloggers on the Internet can explain oauth2.0 in the most humane and easy-to-understand way, it is Mr. Ruan Yifeng. In Mr. Ruan's blog, the oauth2.0 protocol is very easy to understand, and the key is that it is very thorough, so all beginners start from Mr. Ruan's blog. Portal click here.
There are multiple authorization modes in the oauth2.0 protocol:
- Authorization code
- Simplified mode (implicit)
- Password mode (resource owner password credentials)
- Client mode (client credentials)
The four modes have their own advantages and disadvantages, and they all have their own suitable scenarios. I won't go into details here, but the author finally chose to use the authorization code mode because it has the most complete functions and the most rigorous process, and the author has simply docked it before. WeChat's development platform, the authorization process mostly adopts this mode, so I think it will be more suitable (even if other modes are used later, you can switch freely).
The second requirement I received was to find a suitable authorization framework.
Because the author's company has started to study microservices very early, and technically has also implemented a complete set of microservices architecture, it is currently in the stage of continuous service splitting, so there is no doubt that if you make a choice on the framework, in order to be compatible with spring cloud The microservice architecture fits perfectly, and the best and ideal choice is probably the framework of spring security. From the introduction of official documents, it is indeed perfectly integrated with spring cloud, and compared with other frameworks, such as apache's shiro framework, it can also be accessed, and its access cost is not very high, but from the entire technology ecosystem Say, it's not appropriate.
However, the cost of accessing spring security is probably not low, because spring security itself is very heavy, because it itself is a very complete security framework, in addition to authorization, there are functional modules such as serving permission control, and the author has The project is a self-implemented authorization framework, which does not require functional modules such as authority control. If you invest time to transform the original authority framework and use spring security to do it, the cost will undoubtedly be unacceptable to the company.
After thinking about it, I have no clue. There is no suitable framework that can perfectly solve the problems encountered at the moment. Technical ecology (may not find a suitable solution), the main problem is that our api-gateway implementation is very different] In desperation, I bite the bullet and ask my immediate boss to find a better solution.
The boss's original words are as follows:
The reason why our current project does not use spring security is that we did not use it to solve software security problems at the very beginning, so the access cost is very high. In this case, we will implement a set of ouath2.0 by ourselves. The protocol is not difficult to handle. The first version implements the authorization code mode and can be put into use, and the subsequent version iterations can implement other authorization modes.
After struggling for a while, I still formally invested time to research and develop the oauth2.0 protocol. The understanding of the protocol itself can only be regarded as an introduction. Fortunately, there is Mr. Ruan Yifeng's blog.
First understand the relevant noun definitions:
Resource Owner: The resource owner, that is, the user
Resource server: Resource server, that is, the server where the service provider stores the resources generated by the user. It and the authentication server can be the same server or a different server.
Client: third-party application
Authorization server: The authentication server, that is, the server specially used by the service provider to handle authentication
The authorization protocol process of oauth2.0 is roughly as follows:
(A) After the user opens the client, the client asks the user for authorization.
(B) User agrees to grant Client authorization.
(C) The client uses the authorization obtained in the previous step to request a token from the authentication server.
(D) After the authentication server authenticates the client, it confirms that it is correct and agrees to issue the token.
(E) The client uses the token to apply to the resource server to obtain the resource.
(F) The resource server confirms that the token is correct and agrees to open the resource to the client.
The authorization code mode authentication process is as follows:
(A) The user accesses the client, which directs the former to the authentication server.
(B) The user chooses whether to authorize the client.
(C) Assuming that the user grants authorization, the authentication server directs the user to the "redirection URI" (redirection URI) specified in advance by the client, along with an authorization code.
(D) The client receives the authorization code, attaches the earlier "redirect URI", and requests a token from the authentication server. This step is done on the server in the background of the client and is not visible to the user.
(E) The authentication server checks the authorization code and redirection URI, and after confirming that they are correct, sends an access token and a refresh token to the client.
In popular terms, it can be understood as: the user needs to access the system resources, at this time, it should check whether the user has an available (no or expired) token (access token), and if there is no available token, initiate an authorization service to the resource service (from the author For the project, both the external application requests the authentication server to initiate the authorization request). At this time, it is necessary to verify whether the user is authorized (that is, requiring the user to log in to the system, such as opening the login through the app), and then jump to the authorization page after login. The content that needs to be displayed on this page are: the authorization user agreement, and the resources authorized by the user (such as the user Authorization to obtain user nicknames, mobile phone numbers and other resources) and other related information. After the user confirms the authorization, the authentication server sends an authorization code (code). At this time, the client's server gets the authorization code and applies for a token to the authentication server. The authentication server issues the token, and the client server applies to the resource server for open resources after obtaining the token. The resource server checks the validity of the token and decides whether to issue the resource.
Several problems encountered by the author in implementing the first version of the simple open platform are as follows:
A. Authorization related interfaces.
1. Initiate the authorization interface: authorize
2. Confirm the authorization interface: confirm_access
3. Exchange token/refresh token interface: access_token
4, school token: check_token
The implementation of the interface will not be complicated, and spring security is also implemented in this way. There are several built-in authorization-related interfaces, and the related code design can first refer to the simple implementation of spring security. Spring security does a lot of things through filters, but only the authorization-related modules need to be released in advance.
B. Authorized resources
When users enter the authorization page, they need to determine which resources need to be granted to the client to request. This will definitely follow different designs for different businesses. However, a design is generally adopted: the interface is the resource, and the resource group is designed.
Resource is an issue that both authorizing parties need to be very careful about. Users are careful to authorize, and resource servers are careful to open resources to ensure the legality and security of the entire process. Secondly, the allocation of resources is arranged well, which will be very friendly to maintenance and expansion in the later period. For example, resources are open to specific access parties with specific data permissions, or unified open and openable data permissions, and so on.
C, application interface design
The main consideration is how to let them quickly access our application as a third-party access and bring us value. If a set of very unreasonably designed interfaces will cause confusion in the other party's access, high cost, and difficulty in maintenance. A good design solution is very cool for both parties, the access party can access it quickly, and it is very easy to maintain. Isn't it fun? At present, most of the open platform API designs known from the market fall into the following two categories:
1. Bare api interface: For example, the WeChat official account is open, open the open platform document of the WeChat official account, you can see a list of interfaces listed by them. Each interface provides a very demo, calling and debugging are very simple, so the access cost is not high.
2. Unified interface: For example, Taobao's open platform has a unified api address to the outside world, and the parameter method is used as the api name. Taobao's opening provides a very friendly SDK integration, so the integration is fast and the cost will be lower.
Both interface designs have their own advantages and disadvantages. Hard to say which is better. But as far as personal preference is concerned, I tend to like Taobao's api design style. The calling target is very clear. As an access party, I only need to maintain a method list instead of an interface list. I always feel that the maintenance of the interface list will be more laborious. , and if the corresponding SDK is provided, the access can be more convenient and fast.
D. token life cycle management
The most appropriate one should be through the timing expiration of redis, but several situations are involved here (discussed from the perspective of the other party's access)
1. The token never expires. This design is actually not very good, that is, the user authorizes it once and can use it permanently. It is better for the gateway center to do whitelist control on it.
2. The expiration time of the token is very common, ranging from 1 month to one year. This kind of token is actually not suitable for putting it on redis, because the token has existed for too long and the maintenance cost is too high, not to mention the use of the access party. The rate is not very high.
3. The token expiration time is very short, usually a few hours to a few days, and the token can be handed over to redis for management.
4, omitted here...
It is slightly appropriate to consider how to design the token expiration time based on the above scenarios that the access party may use.
E. Interface documentation
Good interface documentation at a glance. Some interface documents are implemented by themselves, which is very laborious, and some are directly generated by third-party plug-ins, which is ideal, such as Swagger documents.
F. Error code
This is a very critical set of information communicated between the access party and the accessed party. The access party can locate and solve the problem very quickly by providing the error code, so a set of good error design is also very important.