Bicycle: cross-site authorization of own projects

It was discussed a lot and for a long time, like in a post ... I implemented my cross-site authorization bike.

So back to the problem:
There are several original projects (project1, project2, projectN ...) for which there should be a single authorization. That is, the User having logged in the project project1 had access to the project2 resources ... projectN as an authorized user.

As a rule, such projects are on a single hosting and it is desirable that they have a common (single) registration. So, if these conditions are met, then the solution described below can continue life in your project.
')
Restriction : all projects are in the same data center and are in the same local network. All projects have a single store for sessions and, accordingly, a single sid.

We agree that:

• project.com is one of the projects.
• sso.com is a general authorization server.

Pledging

• The user on the site project1.com clicks on the link Login.
  *** Alternatively, you can post to url sso.com/signin/project1/#sid
  #sid is the session number
  
• redirecting to sso.com/signin/project1/#sid
• The design of the site project1 is shown, the design of the project is calculated by the query string
  *** If there was a post, then show the design of the project is not necessary and immediately proceed to authorization
• User enters login and password
  *** The item is not needed if there was a post.
• if the authorization is successful, then the serialized (in the form of JSON) is written to the memkey;
  the key is #sid
  next is the redirect to url project.com/welcome/#sid
• redirect to project.com/welcome without session number (#sid)
• if authorization is not successful, then redirect to progect1.com/error/401 (Not authorized)

Authorization

• The user on the site project1.com is included in any section that requires authorization.
• On the server in memkesh, the key is checked, where the key is the session number.
• The key exists, pull out all the necessary data from the profile (User Object) and go on
• The key does not exist, redirect to the login form of the authorization server sso.com/signin/project1/#sid

Authorization from another project

• The user on the site project1.com is included in any section that requires authorization.
• sso.com puts the User object in the memkey using the sid key
• User goes to project2.com/signin/#sid
• The project2.com site is checked, if the #sid key exists, then there is access to all sections of the site.

Output

We kill the key in memkesh or he dies himself

not an extra question

and what if the "alien" decides to log in to url project1.com/signin/#sid using your sid

Yes, it is quite possible ... You can intercept sid in urla with the same probability as intercepting a cookie in which the usual sid is stored.

Conclusion

Unified registration system assumes that the user is registered on sso.com
Access to sso.com data can be from any project. All transitions during registration by analogy with authorization, only the URL is different: sso.com/registration/project1 (project1 shows in which design to display the registration and where to return the user after registration)

Data on sso.com can (but not necessarily) be stored in a key / value database, for example BerkleyDB.

Ps. so that we don’t throw us on the login form too often, you need to use a patch for the memkesh - autoprolongate (about this in another topic)
This patch makes avtoprolongeyt at the same time after the last access to the data.