Paip. Summary of SSO implementation for Synchronous login between modules

Paip. Summary of SSO implementation for Synchronous login between modules

 

Preface...
1

Uniform authentication module...
1

Token exchange...
2

Mixed Mode...
2

Use cookies/sesson for Synchronous login...
2

Use Database-centric token exchange. 3

Remote token exchange...
3

 

Preface

For example, if you have two modules, A and C, and want to log on from a, c also automatically synchronizes the login.

This is an SSO Application Scenario. There are three implementation methods:

One way is to implement a unified Tokey authentication module, suitable for newly designed modules and tightly integrated modules.

The second method is Tokey exchange ....
The connection between the two parties is relatively loose. It is more suitable for integrating existing modules.

Method 3. hybrid mode ..
A large system should adopt a hybrid model to learn from each other...

 

Author attilax
Deduction: 1466519819

 

 

Unified authentication module

 

Use a realistic example for comparison. There are many independent sites inside, and you can buy tickets at the entrance of each attraction. This way of buying tickets is inconvenient. You need to queue up at the door of each attraction to buy tickets. The wallet is easy to lose and unsafe. Therefore, the vast majority of tourists choose to buy a pass (also called a pass) at the gate, they can play all the scenic spots without buying a new ticket. They only need to show the set of tickets they just bought at the door of each scenic spot to be allowed to access each independent scenic spot.

 

 

Unified Tokey authentication, you can use to create a token center... Or take the Tokey of A or B as the standard .. Transform the authentication code of another module... It mainly involves login, registration, login check, logout and other functions ..

This is suitable for the implementation of relatively tight internal module intervals. It is suitable for newly designed modules.

 

Token exchange

 

Examples in reality .. For example, you can use a common cash method to take a bus. You can also switch cash into an IC card in advance to make card swiping more convenient

When you recharge your phone, the IC card does not work. You need to replace the cash with a recharge card to take effect...

Is a one-to-many relationship ..

It is also like a passport. Each country has different effects. When you enter another country, you can switch to another country's idcard for convenience...

 

When you log on to a, generate a token .. When it is switched to B, it is converted to B's token. This method has the least impact on both parties. Independent login and registration ..

 

However, when the user names of both parties are different, a binding is required .. When switching from A to B, you need to change the user name of A to B ..

 

The connection between the two parties is relatively loose. It is more suitable for integrating existing modules.

 

 

Hybrid mode

Hybrid mode .. When we are in China, we speak Chinese and Japanese. But in most countries, we can speak local languages or use general English to communicate...

 

This is the hybrid mode ..

 

A large system should adopt a hybrid model to learn from each other...

Use cookies/sesson for Synchronous Login

When both modules use the same language and run in the same space, switching token using cookies/sessions greatly improves development efficiency .. A calls B's API upon login. Set cookie type.

 

Database-centric token exchange. Remote token exchange

When both parties are remote, you can use the web interface for token exchange ..

 

$ Sign = hash (uname + time + key)

 

B. jsp? (Uname, time, sign)