Detailed explanation of single sign-on with multiple domain names

Hi I'm Shendi


Detailed explanation of single sign-on with multiple domain names




Introduction

I made a login system for my website a long time ago, but because of personal filing and other reasons, there is no need to use the login system, so I didn’t deliberately improve this part of the function, just extract the user part as a microservice

Recently, I wrote a conversion tool to adjust the back-end interface. In order to avoid being called maliciously, in addition to using the verification code, you also need to log in to use it.

Because it is a microservice, there are multiple projects. In order to ensure a good experience, the single-project login is changed to single-sign-on

Because I have never done this part, I first consulted relevant information on the Internet to learn from. After n times of search attempts, I finally gave up. Most of them are full of nonsense, and some even mislead others. Use session to do single sign-on... nothing to gain, so I can only figure it out by myself, so I record it here



Single Sign-On (SSO)

After the traditional login is logged in in one project, it is not logged in in another project status, while single sign-on is logged in in one project, and all projects are logged in

For example, there are two projects, a.com and b.com

After the user logs in at a.com, he directly visits b.com, and the status of b.com is also logged in


You can enter my website to experience the effect

At present, I am trying to log in to other projects after one project is logged in. After one project is logged out, all projects are logged out. If you find a bug, you can send an email to [email protected] to remind me~

  • sdpro.top
  • tool.sdpro.top


train of thought

In the past, I switched the project login by clicking the button. This method is not single sign-on, but it can keep the login status when the project jumps to another project.

Later, I thought about it and found that to achieve single sign-on, only the middle page can be used . The main focus is on the front-end data storage part. As long as multiple projects can share login data, then single sign-on can be realized.


For browsers, the storage data is roughly only cookie, storage


If you put multiple projects under one domain name (single domain name), you can use cookies, which is not much different from traditional login

It seems that subdomains of a domain name can also share cookies, but for me, I have abandoned cookies (because some applets do not support cookies), and the Token I use can only use storage, and the scope of localstorage is In the current domain name, if the domain name is inconsistent, the data cannot be obtained.

So make a page as an intermediate page, and put the login and registration operations on this page.

So how to judge whether to log in? This requires a lot of operations. The pages of other projects have to jump to the middle page at the beginning, and judge whether to log in in the middle page. After logging in, some information will be sent back...

At first, I thought of using iframe, because iframe can use parent to modify the content of the parent window, load the intermediate page in the iframe, call a function of the parent window or change the property value to tell the parent window that the status is login...but after trying , so that it can only be used when the domain name is the same, and if the domain name is different, it will explode across domains

In the end, only redirection can be used. Redirection passing parameters can only be passed through url...

In general, the login information is stored through an intermediate page, and the rest of the items obtain the login information through the intermediate page

Draw a simple picture here to describe the meaning

insert image description here


Among them, the user microservice and the intermediate page are equivalent to the central authentication system CAS (Center Authentication Service)



accomplish

In order to determine the feasibility, I first made a demo example. The two pages are placed under different domain names, mainly for data sharing between different front-end projects.

Project page (url contains info means logged in, jump to intermediate page if not logged in)

<html>
<body>
    wqeqweqwe
<script>
    if (location.href.indexOf("info") != -1) {
      
      
        console.log("已登录");
    } else {
      
      
        location.href = "中间页?url=" + location.href;
    }
</script>
</body>
</html>

middle page

<html>
<body>
<script>
    location.href = location.href.substring(location.href.indexOf("url=")+4,location.href.length) + "?info=123";
</script>
</body>
</html>

After the browser is opened and tried, the effect is not bad, the rest is the logic part, here is a direct summary

User microservice (backend)

  • Using token, the user gets the token after logging in/registering, and the subsequent operation carries the token to pass the login verification
  • Provide login/register/logout interfaces, etc.

project page

  • First determine whether there is login information locally

  • have

    • Represents logged in (maybe login timeout, etc., this needs to be handled by yourself, such as record creation time, if it exceeds, it means invalid, or request the backend backend to inform that the login is invalid..., if it fails, jump to the middle page)
  • none

    • Carry the current page address to jump to the intermediate page (this is a must), and you can also pass more information, such as clearing login information and the like
  • Logout and login also jump to the middle page, just carry extra parameter notifications


middle page

  • Whether there is login information locally, and whether the login information is timed out/invalid
  • Login is valid
    • Carry the page address parameter passed in redirection with login information
  • Invalid login
    • Stay on this page as a login page or redirect back with parameters representing invalid login

Precautions

Because it is a redirection, the length of the url link has a size limit. Different browsers have different limits, and it is about 2000 characters. Therefore, if there is a lot of data, you can save the data to the backend, and the backend returns the logo and then gets the data at the backend.




Finally, one bad thing is that the url part of the browser will jump around, but if you don’t pay attention to the url, it will be refreshed without feeling




END

Guess you like

Origin blog.csdn.net/qq_41806966/article/details/131272287