SSO
Single Sign On
Last updated
Single Sign On
Last updated
Today, most websites require user authentication to access their functionality and content. With the increase in the number of websites, naturally, the number of accounts each user needs will increase. Imagine you are using 10 different services, with each account to access different websites. This service requires at least two basic information: user name and password. Wow, memorizing all this is so tiring! So it's a bit smarter to use the same user name and password for these services. But with 10 services, logging in 10 times is inevitable!!! And so, single sign-on was born
Single Sign-On, as the name suggests, is a mechanism that allows users to access multiple websites and applications with just one login. Once identified on website A, you will also be identified similarly on website B without having to repeat the login process.
Some possible benefits of single sign-on are:
Reduce the number of usernames and passwords that users need to remember
Reduce the number of times you have to enter username and password information
The risk of revealing user information is also moderated
However, a few limitations cannot be ignored:
Development costs when adopting a third service
Depends on external service
Federated Identity Glossary is a place where user information is centralized and linked. There are 4 fundamental elements that make up this system:
Authentication
Authorization
User attributes exchange
User management
Authentication means: checking login information and identifying the user.
Decentralize permissions based on identification information to check user access rights.
Exchange of user information Each subsystem will need and store different user information, however there will be repeated information, such as first name, last name... Therefore, it is necessary to have a place to aggregate this information, and exchange it between subsystems.
User management Admin can manage users by adding, editing, deleting... operations in subsystems.
Single sign-on is part of the federated identity system, closely related to user information authentication. It will identify the user, and then share the identifiable information with subsystems.
When a user logs into system A, A's domain will store identification information in a cookie. So that this user is also logged in when accessing system B, domain B will have to read the cookie created by A. but this is not possible. With today's browsers, domains can only access cookies created by themselves.
Therefore, single sign-on will have to share cookie information between domains. Each single sign-on protocol will have a different sharing mechanism, but the common point is to create a central domain. Through this domain, cookie information will be shared with child domains. For example, the central domain can generate a json web token (jwt) and encode it. When users access the subdomain, they will be redirected to this central domain, and the token will be returned and saved in the browser. After that, if the user continues to access another subdomain, they will similarly be redirected to the central domain, but because this time there is a token, it will be identified and logging in again is no longer necessary. .
After reading it, it seemed quite logical, but when I scrolled down to the questions below, I saw that there was a question with a lot of upvotes like this:
What is browser cookie storage and how it is accessible to by all three apps? I am supposing, the token should be stored by auth server and accessible to auth server, and after authentication browser is sending auth token with each request, and authenticated at auth server side, so why other apps are accessing browser cookie storage?
Since it's a domain specific, private storage, shouldn't the representation of browser storage not have all three domains pointing to it? They don't share the same browser cookie storage. They only share the same information, but in different stores. Is that not correct? I realize that makes the visual a little more disparate, but the principle is an important one to understand and changes the flow slightly.
Understand: how does the browser store cookies? What I understand is that each domain will have its own storage in the total local storage to store cookies. When accessing domain1 and being redirected to the central domain, there will be cookies stored in the storage of domain1 and central. Then, with domain2, how to get the central cookie. I think many people will wonder about this question. (because there are many upvotes ) so there are some insights I want to share:
Local storage is not divided into many sub-storages, but there is only one local storage, all cookies will be stored in one place, in the form of key (domain) and value. It's just that domains will only have access to the data they create.
There is no way domains use each other's cookies. Domains will automatically request to the central domain and automatically store the returned cookies. After that, with each request, the domains will automatically use the cookies they have.
Most current SSO services (for example here is Auth0) have 2 ways to handle this problem:
Due to the nature of cookies, domains and subdomains can be accessed back and forth, so the central domain will be a subdomain for one of the child domains. For example, if the child domain is abc.com , auth0 will create a central domain auth0.abc.com . At that time, if the user has logged in at abc.com , there will be a cookie stored in local storage that both abc.com and auth0.abc.com can access. Then, if the user logs in at edf.com , it will be redirected to the central domain auth0.abc.com , and there will be a cookie, and the user will then be authenticated.
Use Cross-origin resource sharing mechanism
Social login is also a form of single sign-on, which is to use existing login information of social networking systems such as Facebook, Google, ..., users can register for third-party services without no need to create an account. And the central domain will then be the domain of social networks.
