A Complete Developer's Guide to Single Sign On (SSO) For Enterprise Applications
While building SSO for Cloudanix, the team came across quite a few design decisions, options, prioritization crossroads which resulted into this blog post. We felt there is no complete and authoritative guide for a developer and operation teams and so we put this together for you.
We plan to explain, demystify and help you understand about SSO, Oauth, SAML, IDP and various providers like Okta, OneLogin, Auth0, Ping Identity etc.
Let’s get started.
Authentication (and authorization)
Authentication is the process of verifying who you are, while authorization is the process of verifying what you have access to. These two terms are pretty common in apps both consumer and enterprise.
Authentication comes in many flavors and the most common of them is “password” based authentication. Other examples are one time pin, bio-metric or adding a second factor (like SMS) on top of password based authentication. The objective of authentication is making sure the right person can enter the concerned application.
In some documentations, you may come across the following terms too: Principal (entity) wants to authenticate to get access to a System (another entity)
An analogy: Let's say your neighbor is going on a vacation. She comes over and gives you a her house key to water the plants. So, you are authenticating into her house with the key. Only the person who has the "right" key is authorized to enter her house. But let's say she has locked one of the rooms where she doesn't want you to enter as you are authorized to go directly to say, backyard, where the plants are. So, you are authorized to gain access to designated areas. That's the difference between authentication (I am x) Vs authorization (Can I do x).
SSO
Once the popularity of web increased, it became evident that individuals signed up for several applications (running over the web) which they use. Each application had their own set of credentials (login id and password). It is cumbersome for the individuals (user) to remember so many various IDs and passwords. SSO came to help.
SSO stands for Single Sign On.
SSO is a mechanism for authentication where a single pair of credentials can be used across several applications. Imagine, if you went to every application and signed up with the same user id and password and the fact that if you change your password in one application, all the other applications got your new password and now you can log in to those other applications which changed password – All of this effect BUT WITHOUT this implementation of sharing passwords.
How does SSO work?
Since a single identity of a user should be able to get access across multiple service providers, it requires that the authentication process is managed by a single Identity Provider or a Directory Service or some other solution.
This single authentication could be implemented as below
- an LDAP server
- a database
- Active Directory
- Federation based
In simple terms, users can go to an N service providers and they all via LDAP, Trust relationship, or some other SSO protocol go to this “single source of truth” system of records (database) which recognizes the user with the credentials provided.
Now, the terms LDAP, and SSO protocols are nothing but an agreed-upon industry-standard format that various systems understand and recognize. We will see more such acronyms below when we talk Federation.
Federation
In the journey of user authentication there came a moment when this same user spanned across multiple organization (e.g. Multiple SaaS applications is used by the same user of an organization) and security domains.
Federation is part of SSO.
Now when we talk about various systems across security domains and part of multiple organizations talking, we should be clear that there will be variety (and evolution too) of protocols/ languages to accomplish this.
Thus the below acronyms.
- Oauth2
- SAML (1.1/ 2)
- OpenID Connect
- WS-Federation
Two popular open protocols (and third-party providers) are as below:
- SAML 2.0 compliant Identity Provider (IdP) that is configured to communicate with your app (SP).
- Examples of IdP are ADFS, Auth0, Okta, and Ping Identity.
- OpenID Connect (OAuth 2.0) identity management.
Benefits of using Federated SSO
- Single pair of corporate credentials across all your service providers. One user, one password across domains, service providers, and all the various services you access.
- Maintenance of identities becomes simpler with no additional data migration.
- Admin of a corporate finds it easy to manage ex-users of the corporate across several service providers.