Federated Authentication vs. Delegated Authentication: What’s the Difference?

Written by David Worthington on November 8, 2022

Share This Article


Top of Page

The demand for web applications compelled tech vendors to adopt standards that allow authorized users to access resources, across domains, through a single set of credentials. That approach, called federated authentication, has simplified SaaS adoption. However, small and medium-sized enterprises (SMEs) still face barriers when they attempt to extend single sign-on (SSO) to all of their resources. Not every asset is an app, and IT teams struggle to set up access control throughout their entire infrastructure and often turn to complex or siloed systems.

Delegated authentication is a simpler approach that addresses the shortcomings of federated authentication by broadening the protocols (and resources) that your identities can interface with. This article explores both types of authentication in more detail and outlines how an open directory adds more value to your existing identity and access management (IAM) investments.

What Is Federated Authentication?

One identity should log your users into all of their web apps.


Standards of federated authentication including OAuth, OIDC, and SAML make it possible for one identity provider (IdP) to manage access and authorization into many service providers (SP). For instance, that’s what happens when you log into a non-Google service with your Google Workspace credentials. Your credentials don’t pass over the web and the IdP determines whether access is granted. SSO users are managed from a single directory, even if applications have unique entitlements. 

Benefits and Drawbacks

Federated authentication increases productivity, lowers management overhead, simplifies user lifecycle management, and increases security. There’s fewer passwords to manage (assuming passwords are still required) and service providers don’t store credentials. That has the benefit of reducing the risk of identities being compromised from third-party breaches. This form of authentication has given rise to entire ecosystems of cloud-native apps with seamless integrations that wouldn’t have been possible without SSO. Those authentications are protected by other IdP security controls such as multi-factor authentication (MFA). Some IdPs are even adopting more user-friendly and secure passwordless solutions for frictionless access control. 

Entitlement management, through a directory and groups, can enforce least privilege computing to ensure that users don’t become a risk. For example, JumpCloud automates group memberships by continually auditing attributes. The result is that IT admins remember to remove access when one of your team members changes his/her role.

This approach to identity management is auditable and serves to satisfy cloud compliance requirements. Your organization can more easily attest to its compliance by using SSO.

Potential Lock-In

The spirit of openness doesn’t always survive a vendor’s stack. Identity providers and service providers can diminish the intention and effectiveness of using open standards by introducing closed practices and roadblocks. IAM lock-in presents itself in the form of vendor-specific considerations such as integrations with proprietary APIs that are roadblocks to accessing data and features. Spending on development projects for APIs creates a higher cost of switching. Other roadblocks include requiring components and licensing to work with other systems. 

For example, Microsoft’s approach to IAM can obligate organizations to adopt its extended stack including Azure Active Directory (AAD), licensing Windows Server, in addition to either Active Directory Domain Services (AD DS), or Active Directory Federation Service (AD FS) for users to access web apps. That’s because Active Directory wasn’t intended for the internet. Microsoft embraced open standards, but intertwined its monoculture with the IAM services it introduced.

Hidden Costs

Service providers may also upcharge for SSO, a practice that’s dubbed the “SSO Tax.” Interoperability is possible, but it comes at a higher cost per user. The SSO tax runs contrary to the spirit of open standards and may even compromise security if the MFA solution that your organization has implemented can’t function environment-wide. Some IdPs, such as Microsoft, restrict the number of apps your users can access without incurring additional charges. Always consider hidden costs and how subscriptions change over time before you select an IdP or service provider. A directory that provides true federated authentication should make it possible to assemble the optimal stack of services from the vendors of your choosing, without limits.

Accessing Non-Web Apps

SMEs commonly have resources that authenticate using RADIUS or LDAP, including VPNs or Wi-Fi networks. Identity and access management (IAM) suites strive to fill in the gaps when interoperability falls short, but not every solution works the same way. Operational overhead can vary dramatically, depending on the use case, and how those solutions are implemented.

Typically, this work is prerequisite:

  • Installing and provisioning the server
  • Configuring policies
  • Managing user access to the RADIUS server
  • Ongoing maintenance of the server including updating and patching

Without delegated authentication, SMEs must implement dedicated authentication tools that exist independently from IAM infrastructure, creating identity silos, and more work. Other interventions include configuring physical servers such as Microsoft Network Policy Server (NPS) or FreeRADIUS. These setups increase the cyberattack surface area in addition to overall management overhead and operational costs. It can also be cumbersome to integrate those services with your IdP, or a solution may lock you into a specific stack. Cloud RADIUS is another option, but these solutions generally don’t support authentication via an in-place IdP.

Use Cases

SSO protocols make many different scenarios possible.

  • Mobile apps commonly deploy OIDC for SSO, because it’s lightweight, and many of the facilities that developers use are pre-built or available from add-on libraries.
  • Most web apps have SAML built-in, providing an readily available method for federated authentication. IdPs provide pre-built connectors to streamline SSO connectivity. It is also ideal for accessing enterprise apps via a user portal.
  • OAuth 2.0 or OIDC extend federated identity to APIs and microservices architecture.
  • Enterprises sometimes favor SAML due to its capacity for customization and prioritization of secure data exchange.

What Is Delegated Authentication?

Your existing IdP credentials can be used to grant secure access beyond web apps.


Delegated authentication is a standards-based approach (OAuth 2.0 and TLS) that securely brokers established policy and credentials from one IdP to services provided by an open directory. For example, AAD doesn’t offer Cloud RADIUS, but AAD credentials can be leveraged through delegated authentication for seamless and appropriate access into network resources.

Benefits and Drawbacks

The primary benefit is maximizing your existing IAM infrastructure with an in-place IdP while minimizing the number of vendors and siloed solutions necessary to use RADIUS. 

There’s very little technical overhead involved to use delegated authentication and non-centralized logins are eliminated. Delegated authentication reduces the need for IT involvement in RADIUS infrastructure, freeing resources to focus on higher priorities that add business value. This also lowers the potential for security and operational failings through credential sharing and improves the user experience while enabling secure employee Wi-Fi access that segregates out undesirable traffic. Guests and vendors can access your network on a separate VLAN.

Technical constraints restrict authentications to a single factor, but additional security controls such as role-based access control can be layered on for a stronger posture. Group management permits you to achieve fine-grained control of Wi-Fi and VPN access based on established policy and identity settings. JumpCloud has plans to add device-level logins.

Use Cases

The primary use case is authentication for WAP2 Enterprise/802.1x applications, switches, and networking appliances. No configuration is required on device endpoints, and there’s no need for physical servers.

Can Federated and Delegated Authentication Be Used Together?

Federated authentication and delegated authentication are complementary IAM solutions that benefit SMEs that have standardized on IdPs that don’t offer readily available RADIUS services.

screenshot of JumpCloud primary authentication

Try JumpCloud

JumpCloud’s open directory platform consumes identities from established IdPs such as AAD to grant convenient, secure, and appropriate access to RADIUS resources. The platform also provides identity management with environment-wide Push MFA, and LDAP, in addition to cross-OS unified device management. Conditional access rules, patching and password management are also available as add-ons. New accounts are fully functional and free for up to 10 users/devices. Complimentary chat support is available to help you get started.

Sometimes self-service doesn’t get you everything you need. If that’s how you’re feeling, schedule a 30-minute consultation to discuss options for implementation assistance, migration services, custom scripting, and more.

David Worthington

I'm the JumpCloud Champion for Product, Security. JumpCloud certified, security analyst, a one-time tech journalist, and former IT director.

Continue Learning with our Newsletter