Authentication v/s Authorization

I’ve often come across people with a lot of confusion about Authentication & Authorization which is true as there are different types & different technologies involved. In this article I’ve tried to resolve some of the confusion as per my understanding.

• Authentication. This process involves a user’s identity.

For Ex: SAML is a bit like a house key. It grants you access to the facility.

• Authorization. This process involves a user’s privileges.

For Ex: OAuth is a bit like the rules of the house that dictate what the person can and can’t do once inside.

==> SAML v/s OAuth

Security assertion markup language (SAML) is an authentication process. Open authorization (OAuth) is an authorization process. Both applications can be used for web single sign on (SSO), but SAML tends to be specific to a user, while OAuth tends to be specific to an application. The two are not interchangeable, so instead of an outright comparison, we’ll discuss how they work together.

OAuth 2.0: If you’ve ever signed up to a new application and agreed to let it automatically source new contacts via Facebook or your phone contacts, then you’ve likely used OAuth 2.0. This standard provides secure delegated access. That means an application can take actions or access resources from a server on behalf of the user, without them having to share their credentials. It does this by allowing the identity provider (IdP) to issue tokens to third-party applications with the user’s approval.

OpenID Connect: If you’ve used your Google to sign in to applications like YouTube, or Facebook to log into an online shopping cart, then you’re familiar with this authentication option. OpenID Connect is an open standard that organizations use to authenticate users. IdPs use this so that users can sign in to the IdP, and then access other websites and apps without having to log in or share their sign-in information.

OpenID Connect is built on the OAuth 2.0 protocol and uses an additional JSON Web Token (JWT), called an ID token, to standardize areas that OAuth 2.0 leaves up to choice, such as scopes and endpoint discovery. It is specifically focused on user authentication and is widely used to enable user logins on consumer websites and mobile apps.

SAML: You’ve more likely experienced SAML authentication in action in the work environment. For example, it enables you to log into your corporate intranet or IdP and then access numerous additional services, such as Salesforce, Box, or Workday, without having to re-enter your credentials. SAML is an XML-based standard for exchanging authentication and authorization data between IdPs and service providers to verify the user’s identity and permissions, then grant or deny their access to services.

SAML is independent of OAuth, relying on an exchange of messages to authenticate in XML SAML format, as opposed to JWT. It is more commonly used to help enterprise users sign in to multiple applications using a single login.

==> FIM v/s SSO

Much like the name implies, SSO is a function that allows users to access multiple web applications at once, using just one set of credentials. For businesses that deploy various applications for HR, payroll, and communications, an SSO solution allows employees to access each of those services with just one login. This makes it easier for users to do their job — as they no longer have to remember multiple passwords — and also reduces the amount of time IT spends on password resets.

Beyond the workforce, companies can utilize SSO to help customers access various sections of one account. For instance, retail networks with many brands can use SSO to let customers access their accounts with each store from one central dashboard, enhancing their user experience. When shifting between each one, the site re-authenticates users with the same credentials.

As a tool, SSO fits within the broader model of FIM. This model was developed to address the constraints posed by early internet infrastructure, where entities on one domain could not access user information stored in other domains. For companies that operated across various domains, this was particularly problematic, as it made it difficult to create streamlined experiences for employees and customers alike.

As a solution, FIM was developed as a set of agreements and standards that help enterprises and applications share user identities. Essentially, it’s an arrangement that can be made among multiple organizations so that subscribers can use the same identifiers to access various applications. In short, it’s what allows you to sign into Spotify with your Facebook account details.

Added to that, in a FIM system, the onus of reviewing and authenticating user credentials is with an identity provider (IdP), not the applications themselves. So, when a user attempts to log into a specific service provider (SP) or application, the SP then communicates with the IdP to authenticate the user. This user identity authorization is often executed through open-sourced Security Assertion Markup Language (SAML), or other related standards like OAuth or OpenID Connect.

The key difference between SSO and FIM is while SSO is designed to authenticate a single credential across various systems within one organization, federated identity management systems offer single access to a number of applications across various enterprises.

So, while SSO is a function of FIM, having SSO in place won’t necessarily allow for federated identity management. That said, both tools are crucial in supporting organizations with both securing their data and minimizing obstacles in user experience.

==> SSO v/s AD

Microsoft Active Directory is the historical, market share leading, on-prem commercial directory service. Many IT organizations rely upon Active Directory as their core identity provider (IdP) for authenticating resource access to Windows-based systems and applications. AD is offered as a complementary facet of Windows Server.

As Microsoft’s core identity and access management solution, naturally, AD works well in traditional Windows-centric networks. However, AD struggles when non-Windows or cloud-based resources come into play. A few common examples of resources that Active Directory struggles to connect and manage include Google Workspace, AWS, Salesforce, and Dropbox. Of course, the problem gets worse as IT organizations consider the use of macOS and Linux systems, WiFi and VPN networks, on-prem file servers, and much more.

The rise of the internet brought many innovations to the IT industry, one of which was the emergence of web applications. This event presented a major drawback for AD: web apps, which require identity management for proper access and security, exist outside of the traditional domain. To deal with this problem, Microsoft added another solution to the list of AD add-ons, called Active Directory Federation Services (AD FS), in 2003.

ADFS uses the SAML 2.0 protocol to connect an AD identity to a web application. By doing so, AD FS widens the boundaries of the domain to include some web apps, making identity management considerably easier for IT organizations.

With those definitions in mind, let’s examine AD and SSO side by side. AD and SSO are very different; one is an on-prem directory service — the authoritative source of identities, the other a cloud-based, web app identity extension point solution that federates the identities from a core directory to web applications.

ADFS and SSO, however, are very similar. Both solutions federate on-prem identities to cloud applications, filling a great need in modern identity management. Their core differences lie in the fact that AD FS exists on-prem while most modern SSO tools now live almost exclusively on the web.

Microsoft also attempted to fill the role of ADFS on-prem with their Azure Active Directory on the cloud. Azure AD is primarily a user management tool for identities in the Azure cloud suite, as well as Microsoft 365 (formerly Office 365), and it also features limited SAML SSO capabilities akin to those of AD FS and other web application SSO point solutions. This approach still misses non-domain bound IT resources (outside of web apps) and non-Windows solutions, requiring additional AD add-ons that further embed organizations in on-prem infrastructure. Even Microsoft’s reference architecture promotes both AD on-prem and AAD in the cloud along with connective technology called Azure AD Connect, showcasing how entrenched (both technologically and financially) an organization must remain within the Microsoft ecosystem to leverage these capabilities.

==> LDAP v/s SAML

LDAP and SAML are both authentication protocols and are often used for applications, but the two are leveraged for very different use cases

Similarities:

While the differences are fairly significant, at their core, LDAP and SAML SSO are of the same ilk. They are effectively serving the same function — to help users connect to their IT resources. Because of this, they are often used in cooperation by IT organizations and have become staples of the identity management industry. As web application use has dramatically increased, organizations have leveraged SAML-based web application single sign-on solutions in addition to their core directory service.

Difference:

When it comes to their areas of influence, LDAP and SAML SSO are as different as they come. LDAP, of course, is mostly focused toward facilitating on-prem authentication and other server processes. SAML extends user credentials to the cloud and other web applications.

A major difference that is easy to miss between the concepts of SSO and LDAP is that most common LDAP server implementations are driven to be the authoritative identity provider or source of truth for an identity. Most often with SAML implementations, it is not the case that the SAML service is the source of truth, but rather it often acts as a proxy for a directory service, converting that identity and authentication process into a SAML-based flow.

Note: Each time an enterprise deploys a new application, end users have to create a new set of credentials to remember. The result for employees? Too many passwords. In fact, the average user has to remember at least ten passwords every day — but forgets up to three of those every month.

Nearly 40% of employees reuse the same two to four passwords for various accounts, and 10% have just one password for all their applications. This example of weak password hygiene means that it’s now easier than ever for hackers to use stolen credentials to access other critical data — compromising individuals and businesses alike. As it stands, organizations need to be able to provide users with easy access to all of their applications by adopting tools like federated identity management (FIM) and single sign-on (SSO).

Source: Okta Study