Single Sign-On

What is SSO ?

If you're living in the 21st century, you've likely used a mobile app or cloud app which requires some form of authentication. Often times, you'll get two choices, a Single Sign-On (SSO) option using a login you already use frequently, let's say Google or GitHub for instance, or to create your own account and password for that specific application. The latter is more cumbersome but many apps may not have the former option.

Multiple Accounts for each domains

There are many web applications ask to create an user account to login to them to allow to access their resources and contents. In order to do that, you may have to self-signup first and provide the credential to login it. Different domains expect different policies for user name and password. So when you login to 20 sites, you may have almost 20 user accounts with different passwords. This is really hard to maintain.

You have to keep the account details in memory and user to login to the each web application when you want. When you want to change you contact number, then you must change it in all the user profiles in each domains.

How the SSO work

When we consider the above difficulties, don't you think that it would be great if there is one login will allow to all the domain in a specific group which means Single Sign On ?

Single sign-on (SSO) is one of the key features of WSO2 Identity Server that enables users to provide their credentials once and obtain access to multiple applications. The users are not prompted for their credentials when accessing each application until their session is terminated. Additionally, the user can access all these applications without having to log into each and every one of them individually. So, if users log into application A, for example, they would automatically have access to application B as well for the duration of that session without having to re-enter their credentials.

Here you can follow the sequence diagram to get clear the behavior of the SSO flow. The first user login request will continue in regular flow and once you have authenticated user session, then the second login request from the second domain will not be prompted to the user to get the credential again.

Advantages you can have with SSO

Users need only a single username/password pair to access multiple services. Thus they do not have the issue of remembering multiple username/password pairs. Users are authenticated only once at the identity provider and then they are automatically logged into all services within that "trust-domain". This process is more convenient to users since they do not have to provide their username/password at every service provider. Service providers do not have the overhead of managing user identities, which is more convenient for them. User identities are managed at a central point. This is more secure, less complex and easily manageable.

Identity Federation vs. Single Sign-On

Most federated identity management solutions are implemented in a way in which users are not required to prove their identity more than once per logged-in session. Single sign-on is not synonymous with identity federation. However, it is a by-product of the way identity federation is implemented.

On the other hand, not all single sign-on implementations can be categorized as identity federation. For example, Integrated Windows Authentication (IWA) based on kerberos network authentication protocol, is an example of a single sign-on implementation across applications and services, but not considered an example of identity federation because it is limited to a particular network.

IDP initiated and SP initiated SSO

For ref https://blogs.oracle.com/dcarru/sp-vs-idp-initiated-sso​