What is Federation and Why Should Your Apps Support it?

In the days before widespread use of the web, a user would log into a single server (or a handful of servers) and only have to remember one or two passwords. Applications were assumed to be for a single user, and didn’t require login credentials. Then, as the internet began to gain popularity and applications begin to be run on the web, the number of login credentials a user had to memorise increased from just a few, to several dozen. It also meant the number of user stores grew, creating a number of identity silos. User credentials were no longer centralised in a single directory, but spread over a number of systems across the web. Who was going to manage these credentials and how would they do it in an efficient way? Federation was created to solve this problem.

If you’ve ever worked with SaaS products such as SalesForce or Box, you’ve probably heard the term federation. Federation is a process where one system is responsible for the authentication of a user. That system then sends a message to a second system, announcing who the user is, and verifying that they were properly authenticated.

Components of federation

The first system is called the Identity Provider, or IDP. The application is called the Service Provider or SP. The message that is sent between the systems is called an assertion. The assertion contains the account name of the user along with other attributes that the SP needs to create a user session. It is cryptographically signed so the SP can trust that it came from the right IDP. Notice that the SP has nothing to do with the authentication of the user. It trusts the IDP to take care of that. All the SP cares about is that the user was authenticated properly.

But an IDP can be federated to multiple SPs. What does that mean in practice? A user goes to one place to login, then the IDP asserts their identity to the SP that the user is attempting to access. This means there is now a single control point for authentication. By centralising the user’s account and credentials, an administrator has only a single system to perform user management.

Federation at scale

For federation to work on an internet scale, we needed to develop standards that allowed distributed systems, potentially owned by different organisations, to work together. The most widely used today is SAML or Secure Assertion Markup Language. The most current version, SAML 2.0, was adopted in March 2005. SAML 2 provides some great advantages, the biggest being support for SP-initiated login. What that means is the user could navigate directly to the application and would then be routed to the appropriate IDP for authentication. SP-initiated login provides a better user experience by allowing them to go directly to the app they want to use, without navigating to a portal first. Today, most federated applications support SAML 2.

Onward looking for federation, using OpenID Connect

While SAML was cutting edge for its time, by today’s standards it looks very dated. It was designed to enable single sign-on (SSO) from browser-based clients to web servers by passing XML documents. This, of course, predates the mobile era ushered in by the iPhone. Today, modern apps are not always going to be web based, and an assertion using XML is too heavy for today’s uses. Hence, the OpenID Connect spec was born. OpenID Connect is an authentication protocol built on top of OAuth2. Because it is based on OAuth2, it supports a broader set of use cases, like Single Page Applications, mobile apps, and server to server access. It also uses JWT tokens, which are lighter weight compared to SAML’s XML assertions. For more information on OpenID Connect, be sure to visit our OpenID Connect page or read our OAuth2 and OpenID Connect illustrated guide.

Building in federation support—a must have or luxury?

So why should you build support for federation into your application? The answer is simple: in today’s modern world, digital identities are growing exponentially. Every application built comes with it’s own identity. This means your customers, and especially partners, likely already have their own identities, whether from a social application, a custom application, or their enterprise identity. When building a new application, providing a method to bring in an existing identity results in:

• Reduced on-boarding friction The user already has an identity with their existing IDP, so they don’t need to complete a registration flow to create a new account.
• Better user experience By redirecting them to their IDP at authentication time, federation provides a sign-on experience that the user is already familiar with. The user may already have a session with their IDP, so another manual login may be unnecessary.
• Better user management The management of all accounts and credentials are delegated to the user’s organisation, and are no longer the responsibility of the application owner.

These advantages especially apply to any company with a portfolio of applications built for an ecosystem of partners and customers. By unifying your suite of applications with a single identity layer using Okta, you can:

• Connect to external facing IDPs
• Enjoy the benefits of a better user experience
• Leverage an enhanced security posture
• Gain the operational improvements that come from a central user repository

Check out how you can Add Authentication to Any web Page in 10 minutes and explore our Developer Portal. If you would like to learn how Okta can help you bring federation to your applications, please visit our B2B Integration page.