php – A way to implement Single Sign-On (pass-through authorization). Is this method correct?


There is a website called , which acts as an authorization point for (both run on the same engine, working on the principle of a single entry point).

I ask experienced developers for advice on how correct is the following approach to checking user authorization:

  1. When you first visit the site, a cookie is checked with an authorization flag on the site. If there are no cookies, it is redirected to , where it is checked whether an authorization cookie was installed for this user on .

  2. If a cookie was installed, the header('Location: http://' ."12345") is redirected, where token is a random code by which the sessionId for this user is requested from the database.

  3. If we have a token transmitted by a Get request, then after a redirect to, we request a sessionId from the database, start the session session_start(sessionId) , and then make another reboot without the token header('Location: http://' . . The reason is security, it is necessary to remove the token from the address bar.

  4. If the cookie was not installed, we have a guest input of a regular site visitor, for whom the token, which connects it to the sessionId from the database, does not need to be passed. In this case, you need to install a guest cookie so that it is no longer sent to the authorization point for verification. We send the visitor back to the site, for example, in this way header('Location: http://' ."visitor") .

With this implementation, single sign-on will send each site visitor to the authorization point once. How reasonable is this decision, in your opinion?


There can be many sites / domain names associated with , for example, . The purpose of pass-through authorization is the need to provide a user authorized at the authorization point and who owns the site with personal controls (for example, a link to your site like "Мой сайт" ) at the moment when he is on someone else's "Мой сайт" site . As, for example, in LJ, blog owners have a link to their blog from any blog.

All sites are physically located on one server.


session_id(sessionId) – already wrong. Don't do that. That's why:

  1. By default, session files are stored on disk on one server. From the other server, you will see a void, not a session. (What is this loaded system on one server?)
  2. Session files are actually deleted.
  3. Session files may be owned by other users, which means PHP will not be able to read them. At the same time, there is absolutely no debugging output. You will think that the session has begun, but in reality it has not.
  4. Finally, if someone "hijacks" this session ID through XSS or something else, then he can always, as long as your user exists, introduce himself to him.

If the first three points can still be solved through storing sessions in the database or in some other way, then the last point can be bypassed only if you do not do the way you want.

It would be better to start the session as usual with a unique ID, writing the user ID inside the session or whatever you want:

$_SESSION['ID'] = $idFromDatabase;

Farther. There are visitors you cannot send to receive session cookies. For example, search bots. You should either not transfer visitors from public pages to the authorization server, or do it in the background via JS.

Scroll to Top