From Passwords to Cloud Identity: Understanding OAuth, OpenID Connect, Federation, and IAM Through One Story

If you’ve worked with modern applications or cloud platforms, you’ve probably come across terms like OAuth, OpenID Connect (OIDC), Identity Federation, and IAM.

At first glance, they all seem to solve the same problem — something related to authentication or permissions. Yet every time you try to understand one of them, another acronym appears.

• OAuth talks about access tokens.
• OIDC introduces ID tokens.
• Federation talks about trusting external identity providers.
• IAM talks about users, roles, and permissions.

It’s easy to understand each concept individually and still struggle to see how they fit together.

The reason is that these technologies weren’t created independently. Each one was built to solve a problem that the previous solution couldn’t fully address.

In this article, we’re not going to treat them as isolated technologies. Instead, we’ll follow the journey of a single identity, from creating an account, to logging into applications, to accessing cloud resources, and finally to powering modern deployment pipelines.

By the end, my goal isn’t for you to memorize another set of acronyms. It’s for you to have a mental model that naturally explains where OAuth, OpenID Connect, Identity Federation, and IAM fit into the bigger picture.

The Problem

The Problem

Every application on the internet asks you to do the same thing:

Create an account.

Whether it’s Gmail, Spotify, GitHub, your bank, or a cloud platform, each application maintains its own user database.

For users, this means creating and remembering dozens of usernames and passwords.

For developers, it means building the same set of features again and again — user registration, login, password resets, email verification, and secure password storage.

Everyone is solving the same problem, independently.

As the internet grew, this approach became increasingly difficult to manage. Users had too many accounts, and applications had to reinvent authentication for every new product.

Clearly, there had to be a better way.

But before we look at the solutions, let’s first understand the two fundamental questions every application is trying to answer.

Authentication vs Authorization

Before we look at the solutions, let’s first understand the problem every application is trying to solve.

Every application needs to answer two simple questions:

Who are you?

What are you allowed to do?

The first question is about authentication — verifying your identity.

When you log in using a password, sign in with Google, or unlock your phone with your fingerprint, the system is trying to answer:

“Are you really who you claim to be?”

Once your identity has been verified, the next question is:

“Now that I know who you are, what are you allowed to do?”

That’s authorization.

For example, after logging into GitHub, two users may both be successfully authenticated. However, one might be able to merge pull requests, while the other can only view the repository.

Their identity has been verified in both cases. What differs is what they’re authorized to do.

This distinction may seem small, but it’s the foundation of modern identity systems. As we’ll see next, the technologies we’re about to explore solve different parts of this puzzle.

The Password Sharing Problem

Imagine you’re using a photo editing application that lets you import images directly from your Google Drive.

For that to work, the application needs access to your files stored in Google Drive.

One obvious approach would be to ask for your Google username and password.

The application could then log in to your Google account on your behalf and access your files.

But this introduces several problems.

You’re sharing your Google credentials with another application.

The application now has unrestricted access to your account.

And if that application is compromised, your Google account is compromised too.

There had to be a safer way.

Instead of sharing your password, what if you could simply grant the application permission to access only the files it needs — without ever revealing your credentials?

That’s exactly the problem OAuth was designed to solve.

OAuth to the Rescue

Instead of sharing your Google password with the photo editing application, Google can ask you a much simpler question:

“Do you want to allow this application to access your photos?”

If you approve, Google issues the application an Access Token.

The application can now use this token to access only the resources you’ve permitted — without ever knowing your password.

This changes everything.

Your password stays with Google.

The application receives only the permissions it needs.

And you can revoke that access at any time without changing your password.

This is the core idea behind OAuth.

It answers the question:

“Can this application access this user’s resources?”

Notice what OAuth does not answer.

It doesn’t tell the application who the user is.

It only tells the application that it has been granted permission to access certain resources on the user’s behalf.

And that missing piece turns out to be more important than it first appears.

OAuth Isn’t Authentication

At this point, you might be wondering:

“If OAuth only grants permissions, then how does ‘Sign in with Google’ actually work?”

That’s a great question.

Suppose you click “Continue with Google” on a website you’ve never used before.

A few seconds later, you’re logged in.

The website knows:

• Your name
• Your email address
• Your profile picture

But where did this information come from?

Not from OAuth.

Remember, OAuth only answers:

“Can this application access the user’s resources?”

It was never designed to tell an application who the user is.

So while OAuth solved the password-sharing problem, it left another important question unanswered:

“How can an application reliably identify the user who just logged in?”

That missing piece led to the next evolution: OpenID Connect (OIDC).

Enter OpenID Connect (OIDC)

OpenID Connect, or OIDC, builds on top of OAuth to solve the missing identity problem.

When you click “Continue with Google”, Google doesn’t just issue an Access Token.

It also issues an ID Token.

Unlike an Access Token, which is meant for accessing resources, an ID Token contains information about the user, such as:

• Name
• Email address
• A unique user identifier

The application verifies this token and can now confidently identify who has logged in.

In simple terms:

• OAuth answers: “What can this application access?”
• OIDC answers: “Who is the user?”

This is why “Login with Google” is powered by OpenID Connect rather than OAuth alone.

Now we’ve solved authentication for a single application.

But organizations have a much bigger challenge.

They don’t have one application — they have hundreds.

Organizations Need More Than Login

So far, we’ve looked at how a single application can identify a user.

But organizations rarely have just one application.

A typical company might use GitHub for source code, Slack for communication, Jira for project management, Salesforce for CRM, and one or more cloud providers for infrastructure.

Should every employee have a separate username and password for each of these systems?

Technically, they could.

But managing hundreds or thousands of accounts across different applications quickly becomes an operational nightmare.

Instead, organizations prefer to manage identities in one central place — such as Microsoft Entra ID, Okta, Google Workspace, or another identity provider.

Employees authenticate once using their corporate identity.

The other applications simply trust that identity.

This idea is known as Identity Federation.

Instead of every application managing its own users, applications delegate authentication to a trusted Identity Provider.

Identity Federation

So far, we’ve seen how OpenID Connect helps a single application identify a user.

But organizations don’t have just one application — they have dozens, sometimes hundreds.

Think about a typical company. Employees use GitHub for source code, Slack for communication, Jira for project management, cloud providers for infrastructure, and many other internal and external applications.

Imagine if every one of these applications maintained its own user database.

Every time a new employee joined, someone would have to create accounts in every application.

Every time someone left the company, those accounts would have to be disabled everywhere.

This quickly becomes difficult to manage.

Instead, organizations maintain identities in one central place — an Identity Provider (IdP) such as Microsoft Entra ID, Okta, or Google Workspace.

Applications no longer authenticate users themselves. Instead, they trust the Identity Provider to do it on their behalf.

This approach is called Identity Federation.

Notice that Identity Federation is not a protocol like OAuth or OpenID Connect.

It’s an architectural pattern built on trust.

The Identity Provider is responsible for verifying who the user is, and the applications simply trust that verification instead of maintaining their own identities.

Where IAM Fits

At this point, the application knows who you are.

Thanks to Identity Federation, it trusts your Identity Provider to authenticate you.

But authentication alone isn’t enough.

The application still needs to answer one final question:

What are you allowed to do?

This is where Identity and Access Management (IAM) comes in.

IAM defines the permissions associated with an authenticated identity.

For example, two employees might both sign in using the same corporate Identity Provider.

One can deploy applications to production.

The other can only view logs.

Both users are authenticated in exactly the same way.

The difference lies in the permissions assigned to them.

This is why authentication and authorization are separate concerns.

Authentication establishes who you are.

IAM determines what you’re allowed to do.

While different cloud providers implement IAM differently, the underlying idea remains the same:

Once an identity is trusted, IAM decides what that identity is allowed to access.

Putting It All Together

Let’s see how all of these concepts come together in a real-world scenario.

Suppose your organization uses GitHub Actions to deploy an application to AWS.

Traditionally, the deployment pipeline would store long-lived AWS access keys or SSH credentials as secrets.

While this works, those credentials need to be securely stored, rotated, and protected from accidental exposure.

Today, there’s a better approach.

Instead of storing permanent credentials, GitHub authenticates itself to AWS using OpenID Connect (OIDC).

AWS verifies GitHub’s identity because it has been configured to trust GitHub as an Identity Provider. This trust relationship is an example of Identity Federation.

Once GitHub’s identity has been verified, AWS issues temporary credentials for that specific workflow.

Finally, IAM determines what those temporary credentials are allowed to do — whether that’s deploying an application, uploading artifacts to S3, or creating infrastructure.

The credentials automatically expire once the workflow completes.

No long-lived access keys.

No permanent secrets.

Just short-lived, tightly scoped access based on trust.

The same concepts that power “Continue with Google” are also helping modern cloud platforms build more secure deployment pipelines.

Once you understand the role of OAuth, OpenID Connect, Identity Federation, and IAM, they stop feeling like unrelated buzzwords.

Instead, they become different pieces of the same identity story.

Final Thoughts

When I first came across terms like OAuth, OpenID Connect, Identity Federation, and IAM, they felt like unrelated technologies that all seemed to solve the same problem.

The reality is quite different.

Each one exists because the previous solution wasn’t enough.

• OAuth solved the problem of sharing resources without sharing passwords.
• OpenID Connect solved the problem of identifying the user.
• Identity Federation allowed organizations to centralize identities and let applications trust a common Identity Provider.
• IAM answered the final question: what is an authenticated identity allowed to do?

Individually, these concepts are useful.

Together, they form the foundation of modern identity systems — whether you’re clicking “Continue with Google”, signing in to your company’s applications, or deploying infrastructure from a CI/CD pipeline.

The next time you encounter one of these technologies, don’t think of it as another acronym to memorize.

Instead, think of the problem it was designed to solve.

That’s often the easiest way to understand why it exists.