Single Sign On
From ATI Chennai IT and ITES Wiki
Single Sign On
What it is
Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time, hence the name of the feature (Single Sign-on).
For example, if you log in to a Google service such as Gmail, you are automatically authenticated to YouTube, AdSense, Google Analytics, and other Google apps. Likewise, if you log out of your Gmail or other Google apps, you are automatically logged out of all the apps; this is known as Single Logout.
SSO provides a seamless experience for users when using your applications and services. Instead of having to remember separate sets of credentials for each application or service, users can simply log in once and access your full suite of applications.
Whenever users go to a domain that requires authentication, they are redirected to the authentication domain where they may be asked to log in. If the user is already logged in at the authentication domain, they can be immediately redirected to the original domain without signing in again.
How it works
Single Sign-on and Single Logout are possible through the use of sessions. There may be up to three different sessions for a user with SSO:
- Local session maintained by the application
- Authorization Server session, if SSO is enabled
- Identity Provider session, if the user chose to log in through an Identity Provider (such as Google, Facebook, or an enterprise SAML Identity Provider)
With SSO, a central domain performs authentication and then shares the session with other domains. The way a session is shared may differ between SSO protocols, but the general concept is the same.
For example, the authentication domain may generate a signed JSON Web Token (JWT) (encrypted using JSON Web Encryption (JWE)), which contains all the information needed to identify the user for any other domain requiring authentication. This token is passed to the client, but because it is signed, it cannot be modified in any way by the client. The token can be passed to the original domain by a redirect and used by the authentication domain and any other domains to identify the user.
- Security Assertion Markup Language (SAML)
- Web Services Federation (WS-Fed)
- Both SAML and WS-Fed exchange authorization and authentication data in XML format.
- Main parts of this exchange are:
- the user
- the identity provider
- the service provider
With both SAML or WS-Fed, the following workflow is achieved:
- A user requests a resource from the service provider
- The service provider checks with the identity provider for user access to the resource.
- The identity provider verifies the user's identity, and if valid, asserts back to the service provider that the user should have access.
- OpenID COnnect
- Inbound SSO
- Outbound SSO
- Business to Business
- Business to Consumer / Customer Identity Access Management (CIAM)
- Business to Employees
- Build your own Single Sign-on (SSO) system in PHP (16:25 mins video) using Auth0 that depends on Open Auth 2.0 and Open ID
- Active Directory Federation Server | uses Simple SAML PHP for Service and Identity Provision
- SSO Gotchas - Where you can go wrong
- Ajax compatible SSO @ GitHub in PHP - Broker / Server
- Encryption and DIY Quick 'n Dirty SSO
- JSON Web Tokens (JWT) Handbook | Download - 120 pages, 1.64 MB