In the previous lecture, we introduced the basic system related to accounts and authorization, and focused on the logic behind OAuth 2.0. Today we started to consider how to introduce an account and authorization system into QPaint.
The most common approach is, of course, to create an account database yourself, perform login authorization based on username + password, and convert it to a cookie-based session. Examples are as follows:
https://github.com/qiniu/qpaint/tree/v44-bear
https://github.com/qiniu/qpaint/compare/v42...v44-bear
But if we consider providing an Open API, we need to consider following the OAuth 2.0 authorization protocol specification so that third-party applications can quickly access it, instead of spending a long time studying the authorization we invented ourselves.
In addition, we can also consider using OpenID such as WeChat and Alipay to achieve quick login for users, instead of letting users spend half a day in the registration process.
So, the ideal way is for us to provide an account system based on the OpenID Connect protocol and implement it based on the OAuth 2.0 protocol Open API system.
This choice has nothing to do with business. So naturally, we decided to take stock and see if there were any open source projects out there that might have what we had in mind.
Finally, we found that the CoreOS team has launched a project called dex, as follows:
https://github.com/xushiwei/dex (Some dependent libraries are affected by GFW. We adjusted the Makefile to compile based on go -mod=vendor.)< /span>
The dex project describes itself this way:
dex - A federated OpenID Connect providerOpenID Connect Identity (OIDC) and OAuth 2.0 Provider with Pluggable Connectors.
Dex is an identity service that uses OpenID Connect to drive authentication for other apps. Dex acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.
In summary, dex provides an account system based on various mainstream OpenIDs, and the upstream OpenID Provider (i.e., the Upstream IdP in the figure below) is provided in a plug-in manner (Pluggable Connector). This is why it is called federated OpenID. Then, dex provides authorization services to the client (i.e., the Client app in the figure below) through the OAuth 2.0 protocol.
Federation OpenID
Let’s first look at dex’s support for federated OpenID. The currently supported Pluggable Connectors are as follows:
It can be seen that for those OpenIDs that support theOpenID Connect protocol, such as Google, Saleforce, Azure, etc., the same Connector can be used Come support. For other OpenIDs, such as Github, an independent Connector is implemented to support it.
In addition to OpenID Connect, we can also see many familiar open account authorization protocols. For example, in the previous course, someone proposed to talk about single sign-on SAML 2.0 and LDAP. But that's really not our focus. We provide relevant links here for your reference.
The LDAP information is as follows:
The information of SAML 2.0 Web Browser Single-Sign-On is as follows:
https://en.wikipedia.org/wiki/SAML_2.0
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
Different OpenID Providers serve as backends, resulting in some differences in details. Some OpenID Providers do not support refresh tokens (Refresh Token), and some cause ID Tokens to not support the groups field. Details are clearly stated in the above Connector list.
In addition, although dex supports a wide range of OpenID Providers, unfortunately, the mainstream domestic OpenID Providers, such as WeChat and Alipay, are not supported.
But fortunately, it is based on an open plug-in mechanism, and we can implement it ourselves. Pluggable Connector related documents and plug-ins are as follows:
https://godoc.org/github.com/dexidp/dex/connector
Some people in China will also think of doing projects similar to dex, such as:
https://github.com/tiantour/union
We are familiar with WeChat, Alipay, and Sina Weibo, so it is not difficult to come up with ideas, but when you look at the architectural design, you will see a huge gap between the two.
Of course, if you see other good open source implementations, please leave a message to exchange.
Provide OpenID + OAuth 2.0 service
Although there are various OpenID Providers based on the underlying layer of dex, dex provides a unified external standardOpenID Connect protocol and service. OAuth 2.0
As an extension of OAuth 2.0, the most important improvement of OpenID Connect is the introduction of the concept of identity token (ID Token).
Why do we need to extend OAuth 2.0?
Because OAuth 2.0 itself only cares about authorization, it will return access token (Access Token) and update token (Refresh Token). However, neither the access token nor the update token contains identity information. Without identity information, there is no way to function as an OpenID Provider.
Identity Token (ID Token) solves this problem. ID Token is a JSON Web Token (JWT) that allows you to decode the Token and verify the user's identity. For a detailed introduction to JSON Web Token, please refer to https://jwt.io/.
dex is not a package, but an executable program (application), which provides account and authorization services. You can run it like this:
dex config.yamlWhere config.yaml is its configuration file. Please refer to the following examples for its format:
examples/config-dev.yaml(For development purposes, use mock account and authorization service.)
examples/config-ldap.yaml(Based on LDAP for account and authorization services.)
Use dex
With the dex service, we can start to return to the QPaint business to support accounts and authorization.
We don’t need to develop much ourselves.
OAuth 2.0 client SDK, the Go language itself has a quasi-official version. as follows:
package name: golang.org/x/oauth2
Point location:https://github.com/golang/oauth2/
A client SDK for OpenID Connect, one also developed by the CoreOS team. as follows:
https://github.com/coreos/go-oidc
The CoreOS team has also written a detailed documentation on how to connect to dex. as follows:
https://github.com/xushiwei/dex/blob/master/Documentation/using-dex.md
With these instructions for using the SDK and dex, it is relatively simple to specifically connect the QPaint business to dex. We will not go into details here. Please refer to the detailed code:
https://github.com/qiniu/qpaint/tree/v44
https://github.com/qiniu/qpaint/compare/v42...v44
Conclusion
Wrap up today's content. Today we mainly discuss how to transform QPaint’s account and authorization mechanism based on OAuth 2.0. In fact, the industry has very mature practices in this area, so there is no need for us to reinvent the wheel ourselves. Our core idea is to provide an account system based on the OpenID Connect protocol and OAuth 2.0< a i=4> protocol to implement the Open API system.
We not only use standard protocols, but the implementation behind them is also based on an open source project: dex developed by the CoreOS team.
In this way, we can focus on the QPaint business itself.