(Single sign-on is so simple that this example supports IE9+ and IE8 can also be implemented)

Test

Let’s test this example and see how simple it is!

To download this example, you need to download the entire fay-SSO folder, because lib in fay-UC is used by main.js in fay-admin (you can also package it separately for fay-admin, because we often have to interconnect with the server in our project). So I need to add package.json to the parent directory of fay-admin and fay-UC, and of course we need to execute NPM install in the fay-SSO directory

Go to fey-admin, then NPM start, go to fey-UC, then NPM start

The default port for the fey-admin service is 8000, and the default port for the fey-UC service is 8100. You can also change this.

After successful startup, open the browser and enter http://127.0.0.1:8000/. If you are not logged in, it will jump to the login page. Then enter your account password casually and press Enter to jump to the main page.

Security is relative, session is cookie based, so why do we use session for SSO, we can easily use cookie for SSO, request server with token (you can use JWT to implement your token).

Pack to force moment

let us test this example,then see my idea,you will find it is so simple!

download this example,you need down all of fay-sso,because lib of fay-uc is used by main.js of fay-admin,so I need to Json in father of fay-admin and fay-UC,of course,we need NPM install under fay-SSO.

npm install under fay-sso and fay-admin and fay-uc

cd fay-admin and npm start,then cd fay-uc and npm start

The fay-admin’s server port default is 8000, the fay-uc’s server port default is 8100,you can also change it.

All ready,you could open the browser,look for 127.0.0.1:8000,if you not login,it returns to login page,then you input any word to login.You will find it returns to home page and look top right corner.

Let’s change fey-admin’s server port to 8001,and open 127.0.0.1:8001 in your browser,you can find it has logined.Yeah,this is sso.

Safety is relative,session is based on cookie,so why we use session achieve sso? We use cookie completely,then request server with token(you can use jwt).

There is a config.json file in the fey-uc/SRC/directory

  {
    "location": "http://127.0.0.1:8100",
    "postMessageDomain": "http://127.0.0.1:8100",
    "cookieMaxAge": "604800",
    "allowedDomain": [
      "127.0.0.1:8000",
      "*"
    ],
    "secure": "false"
  }
  Copy the code

Location is the domain of fey-UC, postMessageDomain is the domain of fey-admin, postMessageDomain is the domain of fey-UC, cookieMaxAge is the time to remember the password, AllowedDomain allows the domain to use fay-UC for SSO, where * is wildcard. Secure is used to implement HTTPS and is not covered in the code.

How

First of all, the first two pictures, mainly based on these two pictures, you will find that is so simple!

Let me briefly describe: for example, there are now a.com, B.com, UC.com; Iframe is used to nest UC.com in a.com and B.com. Html5 cross-domain communication is used to postMessage to inform UC.com of the login information in A.COM, and then UC.com stores the information to be saved in cookies. A.com will also need to save the information stored in cookies; When visiting B.com at this time, UC.com in iframe of B.com will inform B.com of the login information in the cookie through postMessage, and then B.com will store the information in the cookie. At this time, B.com is already logged in and there is no need to log in again. This enables single sign-on. Above conversely is not logged in.

The previous method is not feasible for Safari and Opera browsers with high security. The difference is that these browsers do not allow cross-domain storage of cookies in iframe. In this case, the solution is to store information in cookies after logging in to the a.com. Then jump to uc.com using iframe nested a.com, a.com will pass the login information in the cookie to UC.com, so that UC.com will get the login information, and then store it in the cookie, and then use the browser path replacement way to enter a.com, so as to achieve single sign-on.

One thing to note: postMessage only sends messages to the agreed field, and iframes are nested only by the agreed field!

Why I do it

Before my project always involves single sign-on is the basic need to use CAS and other frameworks, cumbersome very, very troublesome to change the source code, mainly to achieve a variety of pop-up box login, the specified jump, the separation of the front and back end and so on difficult to control. The server controls the front-end user information basically is the session, and the session is based on cookies, so why don’t we just use cookies? In the days before H5, it was difficult to implement single sign-on with cookies. Now it is easy to implement postMessage with H5. So I decided to implement single sign-on on the front end. My code is very basic, very simple, and frankly nothing. But I struggled with the time when I was starting from nothing. Don’t trust third-party frameworks to implement single sign-on. Security is transparent and relative. It’s best to define a set of security standards internally to prevent attacks.