When designing a system, most of them need a login authorization scheme to ensure access security and permission control. Fortunately, we have frameworks like Spring that work more often with just a few lines of configuration. This has led developers to ignore their workflow and principles and to explore them in this article. Let’s start with the concept of SSO Single Sign On.

SSO&CAS

It is defined as:

SSO allows users to log in once to access all trusted applications in multiple applications. It includes a mechanism to map this primary login to another login for the same user in another application. It is one of the more popular enterprise business integration solutions.

SSO this is a conceptual scheme, of which the famous Yale University CAS system, which we often hear about, is an implementation. CAS Architecture is known for its engineering flow chart as follows:

The core to solve is the introduction of authentication and authentication process, to achieve a single access of multiple systems requires the same set of authorization scheme.

Authentication and authentication

Authentication and Authorization always come together, but they should not be confused.

Simply put, certification is used to determine whether Ming is really Ming. Authorization is limited xiaoming has what permissions, for example, xiaoming can only see this blog can not modify this blog, and I can the author himself.

So how should this process be, each scheme can not always be different, so there is such a standard :OAuth, now has to 2.0, that is, we want to understand OAuth 2.0 today. so

OAuth2.0 is an industry standard Authentication protocol.

OAuth 2.0 focuses on simplicity for client developers, while providing a dedicated authentication process for Web applications, desktop applications, and mobile, and living room devices.

Check out the official workflow description:

+--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant  ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | |  Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+Copy the code

Abstract Protocol Flow, okay, it’s kind of Abstract, especially how the Autorization Grant is done is still unknown. However, we can know that if we want to Access the resource service, we finally get the Access Token allocated by the authorization service. There are several authorization modes of OAuth 2.0, mainly according to the design requirements. Let’s take one of the most complex and perfect patterns to analyze: the authorization code pattern. Again, let’s start with the official explanation:

+----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI ---->| | | User- | | Authorization | | Agent -+----(B)-- User authenticates --->| Server |  | | | | | -+----(C)-- Authorization Code ---<| | +-|----|---+ +---------------+ | | ^ v (A) (C) | | | | | | ^ v | | +---------+ | | | |>---(D)-- Authorization Code ---------' | | Client | & Redirection URI | | | | | |<---(E)----- Access  Token -------------------' +---------+ (w/ Optional Refresh Token)Copy the code

We can see from the picture about the process, when users to access resources must first authorized service authorization, users access authorization service of process by registered agent bring clients good Clent ID and redirection address, authorized service good verify whether it is right after will give to the agent an authorization code, bring authorization code to the client, The client can use this authorization code to obtain an Access Token. As summarized above, only with valid Access Token can we Access our resource service unimpeded.

But… Why is it so complicated? Why not get the Access Token the first time you visit the authorization service with User authenticates in one step instead of using the authorization code to get the Access Token?

The answer is: safety

First of all, the need for such an authorization code is only valid so you don’t use Https to access it, and bloggers poorer than me can’t afford SSL authentication services. Because the problem may be with the way the AccessToken is given to the client, if a direct redirection returns AccessToken, it gives the Hacker an opportunity to hijack the AccessToken. Because urIs can be passed to other malicious sites via HTTP referrer, they can also exist in browser cacher or log files. However, the Authorization Code returned by direct redirection is not sensitive data. The Client key (only held by the Client) needs to be uploaded when the Access Token is obtained through the Authorization Code re-verification. Access with a valid Client Secret is guaranteed to be secure.

If you’re not a poor X like a blogger, implicit Flow is also recommended as an implicit Flow mode, which is faster and safer.

Oltu-oauth2-example oauth2-example oauth2-example oauth2-example oAuth2-example oAuth2-example OAuth2

Draw a flow chart to help understand:

List of Important processes

  • Register an application: Get client_id, client_secret.
  • Request authorization code: Obtain the authorization code auth_code from client_id
  • Access accessToken: Access accessToken with client_id, client_secret, auth_code
  • Access resource services through AccessToken

To request authorization, you need to open the login page, enter the correct user name and password, and return auth_code.