Choosing between delegated authentication vs. federated authentication depends on the nature of your system requirements and IAM framework.

Both forms of authentication verify that the credentials entered are accurate and are, therefore, a vital element of a cybersecurity defense strategy. Both forms of authentication rely on an Identity Provider outside of your Organisation to authenticate your users, underpinned by a trust relationship that you have already configured between the Identity Provider and Service Provider.

This guide will explain these authentication options and the contrasting properties to help identify the critical variations and what they mean!

What Is Delegated Authentication?

Delegated authentication offers a similar experience to Single Sign On (SSO) for end users.

The 'delegation' aspect simply means that your system relies on another to verify the user's credentials.

That might be, for example, a Lightweight Directory Access Protocol server (LDAP), Active Directory or Cloud Application.

In the case of Okta, it’s possible to integrate Active Directory on-premise user store and configure Delegated Authentication. In practise, this means users can sign into Okta with the Active Directory credentials, the user is authenticated by Active Directory in the background and after successful authentication the user is granted access to Okta and then able to access all applications permissioned to them.

How To Set Up Delegated Authentication

Delegated authentication is application and system specific, not all applications are able to offer this feature. In the example of Okta above, delegated authentication is proprietary to the Okta Identity as a Service Cloud Platform. 

Another example of an application offering this feature is Salesforce, it’s possible to configure delegated authentication for an LDAP Server, the user will be able to log into Salesforce directly with the LDAP credentials.

At the integration stage, this depends on the applications in scope.

In the example of Okta’s delegated authentication to Active Directory, the login experience, behind the scenes, works like this:

1. A user enters their existing username and password in the Okta sign in page
2. The user credentials are sent securely to the Active Directory end point to be verified 
3. The username and password are validated by the Active Directory Domain Controller, which provides a true or false result.
4. If the result is true, the login proceeds. If false, they receive an error advising that the username and password are not valid.

Risks Associated With Delegated Login Authentication

While delegated authentication has benefits, some risks make it potentially less secure than federated authentication:

• Inherently, there is a greater risk in any login process where data (even if encrypted) is passed to a third party. 
• Implementing a delegated authentication process can take time and effort to configure the endpoint to integrate seamlessly with the business digital site or app.

The exposure to data breaches is why some groups do not permit third-party network password handling.

How Does Federated Authentication Work?

Federated authentication—or federated identity management (FIM)-is an agreement between an Organization and an Identity Provider, that the Identity Provider (e.g Social Login or Microsoft’s ADFS) will authenticate the user in line with industry best practices, thus the Organization no longer has to manage the authentication process or end user credentials. Common examples in the customer identity world are services which allow end users to log in with their existing Social Network credentials e.g. Google and Facebook.

Users can log in once to access affiliated networks or websites, even if they host a separate login portal.

The identity provider stores user credentials and validates new logins.

IAM in federated cloud applications involves a trust relationship between the Organisation (Service Provider) and 3rd Party Identity Provider so that users can sign in with credentials verified by the IdP.

Benefits And Risks Of Federated Authentication Protocols

Federated authentication works well where organizations or affiliates work together and require users to share resources or access each other's domains.

Other examples exist in Customer Identity where one user has access to multiple domains with one set of login credentials—for example, individuals logging into social media sites such as Google and Facebook.

Administrators of the organisation no longer have to manage authentication protocols and instead can focus on authorization, or in other words, can define the appropriate access levels for users across systems and security domains, once the user has successfully gained access.

The pitfall is that each organization within the identity federation needs to develop access policies with equal compliance across participating affiliates.

That may seem like a simple administrative task, but it can be challenging when entities work in conjunction yet have very different cultures and security protocols.

How To Choose Between Federated And Delegated Authentication

Delegated authentication is preferable for Employee Identity scenarios, where e.g. existing employee credentials are required to be leveraged for partner or customer portals.

However, between the two options, federated authentication is the more flexible and provides a broader method of interconnecting access management permissions.

Logins for everyday platforms such as Google use federated identity management to authenticate user access.

The global economic advantage is that associated businesses don't need to duplicate information, users are more traceable, and the experience is improved with minimal logins required to access multiple systems.

For further reading, check out our other articles like Define Privileged Access Management.