SSO (single sign-on) is a concept that allows you to access and use more than one service with a single user ID. Let's give an example to understand this concept better.
- Normally, when a user wants to use any service, the user encounters the login screen of that service, logs in with a username and password, and a cookie is created for this service in the browser.
- When the user wants to use another service, the user encounters the login screen of that service, logs in with a username and password, and again a cookie is created for this service in the browser. This process is repeated for every service or application the user wants to use.
In this case, the user spends time creating an account for each service separately and logging in. Changing the passwords of these accounts regularly costs time, and on top of that, using the same password for all services creates a security weakness.
How does single sign-on work?
There are basically three types of elements in the SSO concept. These are:
- Identity provider
- Server
- Clients (browsers, mobile applications, etc.)
In practice, SSO is usually implemented with open standards such as SAML or OIDC.
The user who wants to use a service is directed to the login page of the authorization server (IdP) and usually logs in with their username and password.
There are alternative login methods, such as passwordless login, in Monosign.
Then, the server (IdP) authenticates the user and creates a session-specific key (session token). With this key, the user is directed back to the page of the service they want to use. This token can also be used by other related services. In other words, the authorized user can connect to all services they have access to on the same SSO platform without entering their password again.
When the user wants to use another service belonging to the same SSO system, that service checks the user's session token with the authorization server and allows the user in if it receives a positive response. If the token is not approved by the authorization server, the user is directed to the authorization server's login page and the login process is repeated. With this method, the password is used only on the authorization server, and no time is wasted on the login process of each individual service or application.
