Cross-Site Authorization (SSO)
There is a task - to organize cross-site authorization between projects hosted on different domains (site1.com, site2.com). The user having authorized on one project is authorized on all (Single Sign On). The same with the exit button (Single Sign Out). Each project has access to the session storage and database.
In two days I shoveled a lot of articles and discussions. The conclusion - I could not find a standard solution for my case (I did not consider solutions for intranets and sites with a clearly divided open / closed zone).
Update: Continuing the history of cross-site authorization 2 .
')
The basis of this option is a centralized authorization server and HTTP redirects.
1. The user enters the login password and post the form.
2. We encrypt the login + password + return url + url with incorrect login / password + lifetime (no more than 30 seconds) c the possibility of decryption and we get a unique token.
3. We make a redirect to the authorization server by passing the received token in the parameter.
4. Authorization server decrypts it and performs authorization.
5. Authorization passed: set the cookie, raise the session and generate the token (session id and token lifetime). Login / password is not correct: instead of a token - the flag that the authorization failed.
6. Authorization server redirects to the reverse URL with the received parameter.
7. Decrypt the token and set the cookie.
8. We redirect ourselves to clear the URL in the address bar.
1. The user enters the site. We check if there is a cookie, if we raise a session, if not, then go ahead.
2. We redirect to the authorization server with the encrypted return address.
3. Authorization server checks if there is a cookie.
4. If there is, then we encrypt the token with the session id and the token lifetime, if not then there is a flag that there is no cookie.
5. We do a redirect back with the received parameter.
6. Decrypt the token and set the cookie.
7. We redirect ourselves to clear the URL in the address bar.
1. Remove the cookie and encrypt the return url.
2. We redirect to the authorization server with the return url and delete the session and cookie.
2. Remove the user binding to the session in the database (in my users table, each user maintains his current session in order to raise it by cookies).
3. Make a redirect back.
From the pros I want to note that everything works using the usual HTTP protocol without the use of additional technologies.
The minus is quite large and is associated with cookie authorization: if the user has cookies disabled or the robot has come to us, then a nightmare begins: for each of his requests there will be 3 redirects + a new session will be created.
There are 2 options for solving this problem:
1. Instead of a redirect, connect JavaScript from the authorization server, which, if there is a cookie, will raise the session and put a cookie on the site. But this solution also has disadvantages: as I understand it, there are problems with Safari and authorization by cookies will not work if JavaScript is disabled.
2. Try to set fire to the one who does not save cookies (mostly robots). You can parse the XML file from www.user-agents.org and shove it into some MemcacheDb and check with each request. Or try to set a cookie, if it does not work then save the IP (you can with the User Agent) in the same MemcacheDb and also check with each request. You can combine both methods.
Features of this option that does not need an authorization server and robots are not terrible, and also works with disabled JavaScript. Although the decision to be honest is not the most beautiful.
1. The user enters the login / password and will post the form.
2. Authorize, set the cookie, raise the session.
3. Create a token: encrypt the session id and the token lifetime.
5. Show one pixel image for each domain with a token in the URL.
6. Pictures (scripts that give pictures) decode tokens and put cookies on each domain (do not forget to give the P3P header: CP = "IDC DSP COR ADM DEVI TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT").
Cookies are already on all domains.
1. Delete cookies and session.
3. Create a token: encrypt the session id and the token lifetime.
4. Show pictures from each domain with a token in the URL.
5. Pictures decrypt tokens and delete cookies.
Of the minuses: cookie authorization does not work if pictures are disabled. Every domain / project should know about everyone else.
I myself did not choose which option to use, so I decided to discuss this topic with you in order to find problem areas and come to an optimal solution.
In two days I shoveled a lot of articles and discussions. The conclusion - I could not find a standard solution for my case (I did not consider solutions for intranets and sites with a clearly divided open / closed zone).
Update: Continuing the history of cross-site authorization 2 .
')
Option 1
The basis of this option is a centralized authorization server and HTTP redirects.
Entrance:
1. The user enters the login password and post the form.
2. We encrypt the login + password + return url + url with incorrect login / password + lifetime (no more than 30 seconds) c the possibility of decryption and we get a unique token.
3. We make a redirect to the authorization server by passing the received token in the parameter.
4. Authorization server decrypts it and performs authorization.
5. Authorization passed: set the cookie, raise the session and generate the token (session id and token lifetime). Login / password is not correct: instead of a token - the flag that the authorization failed.
6. Authorization server redirects to the reverse URL with the received parameter.
7. Decrypt the token and set the cookie.
8. We redirect ourselves to clear the URL in the address bar.
Cookie authorization
1. The user enters the site. We check if there is a cookie, if we raise a session, if not, then go ahead.
2. We redirect to the authorization server with the encrypted return address.
3. Authorization server checks if there is a cookie.
4. If there is, then we encrypt the token with the session id and the token lifetime, if not then there is a flag that there is no cookie.
5. We do a redirect back with the received parameter.
6. Decrypt the token and set the cookie.
7. We redirect ourselves to clear the URL in the address bar.
Output
1. Remove the cookie and encrypt the return url.
2. We redirect to the authorization server with the return url and delete the session and cookie.
2. Remove the user binding to the session in the database (in my users table, each user maintains his current session in order to raise it by cookies).
3. Make a redirect back.
From the pros I want to note that everything works using the usual HTTP protocol without the use of additional technologies.
The minus is quite large and is associated with cookie authorization: if the user has cookies disabled or the robot has come to us, then a nightmare begins: for each of his requests there will be 3 redirects + a new session will be created.
There are 2 options for solving this problem:
1. Instead of a redirect, connect JavaScript from the authorization server, which, if there is a cookie, will raise the session and put a cookie on the site. But this solution also has disadvantages: as I understand it, there are problems with Safari and authorization by cookies will not work if JavaScript is disabled.
2. Try to set fire to the one who does not save cookies (mostly robots). You can parse the XML file from www.user-agents.org and shove it into some MemcacheDb and check with each request. Or try to set a cookie, if it does not work then save the IP (you can with the User Agent) in the same MemcacheDb and also check with each request. You can combine both methods.
Option 2
Features of this option that does not need an authorization server and robots are not terrible, and also works with disabled JavaScript. Although the decision to be honest is not the most beautiful.
entrance
1. The user enters the login / password and will post the form.
2. Authorize, set the cookie, raise the session.
3. Create a token: encrypt the session id and the token lifetime.
5. Show one pixel image for each domain with a token in the URL.
6. Pictures (scripts that give pictures) decode tokens and put cookies on each domain (do not forget to give the P3P header: CP = "IDC DSP COR ADM DEVI TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT").
Cookie authorization
Cookies are already on all domains.
Output
1. Delete cookies and session.
3. Create a token: encrypt the session id and the token lifetime.
4. Show pictures from each domain with a token in the URL.
5. Pictures decrypt tokens and delete cookies.
Of the minuses: cookie authorization does not work if pictures are disabled. Every domain / project should know about everyone else.
I myself did not choose which option to use, so I decided to discuss this topic with you in order to find problem areas and come to an optimal solution.
Source: https://habr.com/ru/post/64002/
All Articles