Why IAM Exists

Almost nothing in software runs alone. A frontend calls an API. That API calls three more. Somewhere a human is clicking buttons. Every one of those hops needs to answer two questions:

  • Who is this? (authentication)
  • What are they allowed to do? (authorization)

On a whiteboard, both look trivial. In practice, they get ugly the moment more than one app shows up, or more than one team has to share the answer.

The problem in one picture

Say you ship three apps: a customer web app, an internal admin tool, a mobile app. Each one needs login. Without IAM, you’d:

  • Store passwords in three databases.
  • Build “forgot password,” MFA, and lockout three times.
  • Reimplement session handling, token issuance, and revocation in every app.
  • Reinvent permissions every time someone ships a feature.

Most teams notice this somewhere around app number two and start cutting corners. An IAM system is the way out: one trusted service that every app delegates to. That service speaks a handful of protocols, and those protocols are what this section is about.

The standards you will meet

Each standard solves one slice of the IAM problem:

How to read this section

Read in any order. Every page is meant to stand on its own. Two reasonable starting points:

  • Start with OAuth2 if you’ve ever wondered why “Login with Google” works the way it does, or if you’re building an API that other apps will call.
  • Start with JWT if you’ve hit a real token in the wild and you just want to know what’s inside it before zooming out.

Every page ends with an “In FerrisKey” section pointing to where the concept lives in the product.

In FerrisKey

FerrisKey implements the protocols described in this section. To see them in practice: