Mall - authority - the principle of non-state login

1. Log principle of non-state

1.1. What is the status?

Stateful service, i.e., the server needs to be recorded per session client information to identify client identity, processing, typical design such as tomcat session request according to a user identity.

For example Login: user login, we registrant information stored in the server-side session, and give the user a cookie value, recording the corresponding session. Then the next request, the user carries the cookie values, we will be able to identify the corresponding session, to find information about users.

What are the disadvantages?

• Server to save large amounts of data, increase the service side pressure
• The server saves the user state level can not be extended
• Client requests depend on the service side, repeated requests must access the same server

1.2. What is stateless

Micro-services cluster each service, are provided outside Rest-style interface. And one of the most important specifications Rest style is: no service state, that is:

• The server does not store any client information requester
• Each client must have the self-describing information request, information identifying the Client by side

What benefits is it?

• The client requests information does not depend on the service side, do not need any more requests to have access to the same services
• Server clustering and state transparent to the client
• The server can migrate any and telescopic
• Reducing the pressure storage server

1.3. How to achieve a stateless

Stateless login process:

• When a client requests a service for the first time, the server the user authentication information (login)
• Authentication, the user information is encrypted token form, back to the client, as the login credentials
• After each request, the client carries authentication token
• The server to decrypt the token to determine whether valid.

flow chart:

The entire login process, what is the most critical point?

security token

token is the unique identifier to identify the client's identity, if encryption is not tight, it finished being forged.

How secure is the encryption using it?

We will useJWT + RSA非对称加密

1.4.JWT

1.4.1 Introduction

JWT, stands for Json Web Token, JSON is a lightweight style authorization and authentication specification, enabling stateless, distributed Web application authorization; official website: https://jwt.io

Jwt on GitHub java client: https://github.com/jwtk/jjwt

1.4.2 Data Format

JWT data comprising three parts:

• Header: the head, the head usually has two pieces of information:

  • Declared type, here is the JWT
  • Encryption algorithms, custom

  We will head base64-encrypt (decrypt available), to give the first portion of the data

• Payload: payload is valid data, typically contains the following information:

  • User identity information (note that here because the use of base64 encryption, decryption, so do not store sensitive information)
  • Registration Statement: As token of the issue of time, the expiration time, the issuer, etc.

  This part will be base64 encrypted data to give a second portion

• Signature: Signature, authentication information is the whole data. The first two steps of the general data, coupled with the service key (Secret) (not leak, preferably replaced periodically), generated by the encryption algorithm. It used to verify data integrity and reliability of the entire

Generating data format:

Can be seen divided into three segments, the above data is part

1.4.3.JWT interaction flow

flow chart:

Translation steps:

• 1, a user logs
• 2, the authentication service, by generating a token according to the secret
• 3, the generated token back to the browser
• 4, each request carries the user token
• 5, jwt interpretation service using the public key signature, the signature is valid after the determination, the user information acquired from the Payload
• 6, processes the request, it returns a response result

Because the token JWT issued already contains a user's identity information, and each request would carry, such services do not need to store user information without even having to query the database in full compliance with the stateless Rest norms.

1.4.4. Asymmetric encryption

Encryption is the information encoding and decoding technology, the original code is readable information (also known as plaintext) translated code form (also known as ciphertext), the decoding process is the inverse (decryption), the encrypted encryption key points algorithm, encryption algorithm can be divided into three categories:

• Symmetric encryption, such as AES
  • Rationale: The plaintext into N groups, and then use the key to encrypt individual groups, each formed ciphertext, and finally all the ciphertext packets combined to form the final ciphertext.
  • Advantages: public algorithm, a small amount of computation, fast encryption speed, high efficiency encryption
  • Defects: Both sides use the same key, security can not be guaranteed
• Asymmetric encryption, such as RSA
  • Rationale: simultaneously generate two keys: a public key and a private key, the private key secret preservation, public key can be distributed under the trust clients
    • Private key encryption, hold private or public key can decrypt
    • Public key encryption, before holding a private key to decrypt
  • Advantages: safety, difficult to crack
  • Disadvantages: time-consuming algorithms
• Irreversible encryption, such as MD5, SHA
  • Rationale: The process does not require the use of encryption keys , the encrypted input plaintext algorithm processing directly into ciphertext by the system, this data can not be decrypted is encrypted, the ciphertext can not be calculated according to plaintext.

RSA algorithm history:

In 1977, three mathematicians Rivest, Shamir and Adleman devised an algorithm that can achieve asymmetric encryption. The algorithm used their three initials: RSA

1.5. Authentication process of binding Zuul

We gradual evolution of system architecture design. Note that: secret is the key signature, and therefore must be kept confidential, we put the authentication center to save, any other services can obtain a secret.

1.5.1. Without RSA encryption

In the micro-service architecture, we can operate an authentication service into the gateway, will not directly by requesting authorization to intercept, as:

• 1, the user logon requests
• 2, Zuul forwards the request to the authorization center, requesting authorization
• 3. The authority check is complete, the certificate issued by JWT
• 4, the client requests other functionality, carrying JWT
• 5, Zuul jwt the authorization center to check, after release by
• 6, the user service request reaches the micro
• 7, micro-services will jwt to the authentication center, while parsing user authentication information
• 8, Authentication Center returns the user to the micro-data services
• 9, the micro-service processing request, returns a response

Find out what the problem?

Each time authentication is required to access authentication center, network system between the request frequency is too high, slightly worse efficiency, greater pressure Authentication Center.

1.5.2 Combined with RSA authentication

Direct Figure:

• We first generated using the RSA public and private keys. Private key stored in the authority, a public key stored in each micro Zuul and services
• User requests to access
• Authorities check, after the adoption of JWT is signed with a private key encryption
• Jwt returned to the user
• Users carry JWT access
• Zuul directly through the JWT public key to decrypt, validate, verification is released
• Service request arrives micro, micro-analytical services with the public directly JWT, obtain user information, no access authorization center