suppose, you have developed applications with different domains(like domain A, domain B domain C …). and you want the same login information for all domain. like, if user who are already logged-in at domain A to get logged-in at domain B and domain C too. This whole process is called as SSO.
What are the types of SSO-
SAML, or Security Assertion Markup Language, is a protocol or set of rules that applications use to exchange authentication information with the SSO service. SAML uses XML, a browser-friendly markup language, to exchange user identification data. SAML-based SSO services provide better security and flexibility, as applications do not need to store user credentials on their system.
OAuth, or Open Authorization, is an open standard that allows applications to securely gain access to user information from other websites without giving them the password. Instead of requesting user passwords, applications use OAuth to gain user permission to access password-protected data. OAuth establishes trust between applications through API, which allows the application to send and respond to authentication requests in an established framework.
OpenID is a way to use a single set of user credentials to access multiple sites. It allows the service provider to assume the role of authenticating the user credentials. Instead of passing an authentication token to a third-party identity provider, web applications use OIDC to request additional information and validate the user’s authenticity.
How SSO Works —
Different SSO protocols share session information in different ways, but the essential concept is the same. there is a central domain, through which authentication is performed, and then the session is shared with other domains in some way.
The user requests a resource from their desired application/website.
The application/website redirects the user to the Identity Provider for authentication, using SAML, OpenID Connect, etc.
The identity provider authenticates the user and passes a token to the SSO server.
The SSO server delivers the token to the application.
The application grants access to the user.
SSO relies on a centralized server that all applications trust. On this central server, a cookie is created when you log in for the first time. Then, if you try to visit a second app, you’ll be redirected to the central server. If you already have a cookie, you’ll be redirected directly to the app with a token, bypassing the log in question, indicating that you’re ready to go.
Note — Regardless of the platform or application you use, it is feasible to make a solitary sign-on for every one of them. To do this, you need one central server that every application can get to.
Implementation By Code — Click to get implementation part