Photo by Georg Bommeli on Unsplash

Auth acronyms explained — part 1

On a difference between FIM and SSO. Introducing SPs and IdPs.

As a data engineer, it is easy for me to get lost in all those acronyms. DevOps friends of mine don’t have much of a problem but hey, not everyone is a DevOps engineer! You might be lost just as I was a few months ago. In this article series I am explaining commonly used acronyms in authorization and authentication space.

Authentication and authorization

Let’s start with the basics. I found that for non-native English speakers, these two terms are often confused. Let’s revise then, shall we?

Authentication is a process of identifying who the user is. One-time magic links, passwords, MFA apps are means of verifying that the user has access to the account they claim belongs to them.

Authorization on the other hand happens after successful authentication. It is connected with roles, permissions and actions that the user can make in the system.

On federated architectures

In general, a federation is an architectural pattern for allowing interoperability and information sharing in autonomous, possibly decentralized systems. Systems establish secure communication channels for data exchange. That way systems don’t have to duplicate the information stored for a certain entity. Imagine using two apps that interact with your calendar. You can use OAuth 2.0 to give access to your Google calendar to both applications. These three parties (two apps and Google) would form a federation.

Federations come with all shape and sizes — from internal microservices to cross-domain SaaS platforms. Given the recent cloud evolution, federations are omnipresent. And one of the main use cases for federations is identity management.

Federated Identity Management

Storing and securing identity information has always been a challenge. Back in the days where we used passwords to log in to all websites, oftentimes people reused the same passwords over and over again. It isn’t uncommon that some websites aren’t treating security as first class citizen. Database leaks happen every day. But we, as the users, we are getting smarter. We have password managers, MFAs and all.

Just as in life you are better off doing a handful of things and doing them right, we would prefer to build systems that do a few things right. With FIM (Federated Identity Management) there is one party in the federation that is responsible for identity management. This party is called IdP (Identity Provider).

If you haven’t been living under a rock for the past 10 years you probably heard about Facebook, Google, Microsoft, Apple or Okta — and have probably seen Sign in with Google button somewhere. Signing in is just one part of the broader identity management space — namely authentication. With FIM and leveraging protocols such as OAuth, FIM system can provide complex user identity solution by providing both authentication and authorization capabilities.

Single Sign-On

Federated Identity Management wouldn’t exist if not SSO (Single Sign-On). The general idea behind SSO is to have one set of credentials to access all applications within organization or across many organizations (like many SaaS platforms). This definition is not accurate though, having a password manager would technically also satisfy this condition — after all, all you need to remember is your master password. The applications that you try to access must establish a trust relationship for the system to be considered an SSO. Otherwise, it would be something that we could refer to as Same Sign-On.

Is that that much of a difference you might ask? Actually yes. With Same Sign-On applications aren’t forming a federation. Each app keeps track of their own set of credentials (like user and password stored in your password manager) and there is no central authority to ask for the user roles (thus — authorization is decentralized and harder to manage). By maintaining their own identity management mechanisms, applications need to enforce security measures on their user — making it burdensome to work with. Just imagine having to change password or performing MFA authentication monthly for 60 apps that your company uses.

SSO can kind of exist without federation though. Federation is usually connected with decentralized and autonomous systems. Accessing your Google account for Gmail, Calendar and Meets isn’t technically a federation — under the hood these are separate products (yet not entirely autonomous), you use same set of credentials to access them, and they have trust relationship between each other. Thus, this setup can be considered an unfederated SSO.

The difference between SSO and FIM

As you can see, SSO is a part of FIM but FIM has way more to it. In every day language though, what people mean by SSO is usually FIM. With so many so popular SasS products federations are so ubiquitous now that unfederated SSO is not even considered a thing anymore. Just as the regular user isn’t even aware of the complexity of Facebook’s backend services, people doesn’t give a damn about FIM if all they see is SSO.

Risks and myths about SSO

In IT we usually aim at as much decentralization as possible, yet SSO may be perceived as a bit controversial. Is this an architectural flaw and single point of failure? In some sense, yes but there are many caveats to this

• what alternative do we have? Having so many applications with different authentication mechanisms while enforcing strong password policies would not be productive to work with to say the least. Not to mention the operational burden,
• majority of people would still use the same password to all independent systems,
• it is easier to establish really strong password / account protection policy with MFA, magic links, physical authentication devices to protect single set of credentials rather than multiple,
• with FIM and IAM onboarding new users, controlling their permissions and eventually decommissioning users is so much simpler.

I would argue that in the end human is the single point of failure of any system when it comes to identity management. It should be in our best interest to create systems that make it hard for them to become a victim of phishing and other threats.

Conclusion

In this article we explained the difference between FIM and SSO. For regular person, understanding the difference is not really that important and for easing your mental burden I would suggest you to consider them both SSO (technically FIM is sometimes referred to as federated SSO). The key point is to remember that SSO is about trust between parties — applications (SPs) and IdPs. Without the trust, there is no centralized governing body and we can’t benefit from the things that this model provides.

Appendix 1: SSO provider

SSO provider (actually FIM provider) is a middleman. They connect apps (SPs, Service Providers) and IdPs. It is a central body that would determine if the user’s browser has already been authenticated by the IdP. You can think of it as a cache for authentication tokens from IdPs.

Some SSO flows doesn’t distinguish this component as separate entity. For instance, with Google authentication you talk directly with Google servers and there is no middlemen. With Okta’s external provider, Okta would be such middleman.

Appendix 2: How does FIM work?

I don’t think understanding the technical flow is all that important but just for completeness I will include it. This flow is sometimes described on the Internet as SSO but given that there are multiple, possibly independent parties involved, I think it is more accurate to describe it as a FIM flow. Nonetheless, you will get the idea. We focus on pure authentication now.

1. The user tries to access an app. The app can’t find a session token nor cookie, user needs to be authenticated. The app will issue a request with a secret token and with information about their identity. Given e.g. the subdomain the app will know to which SSO provider to redirect the user to.
2. User is redirected to SSO provider. If they are already authenticated (again, this can be verified as a session token or a cookie but against SSO provider domain), they will be redirected back to the app — we go to point 5.
3. If not, the user will be redirected to the IdP. The request will contain secret token of the SP and the information about requester. IdP will confirm the secret token — the two parties established trusted relationship, they share some form of cryptographic secret to communicate securely. Afterwards, it might ask user to log in or provide MFA code if they can’t find the user session.
4. Using the secret, IdP will generate access token that will be passed to SSO provider for caching and later to the app (SP).
5. The app verifies the access token by using the means of trust with the IdP. On successful validation, they establish a session for the user. Access token will contain information about the user roles (e.g. by the use of SAML — something that we will explore in the future posts).

Note that concrete implementations may differ from the flow I presented here. The general idea is similar though.

This is part 1 of my article series on auth acronyms. Check out part 2 here.