In digital identity, two terms are often used interchangeably, but they mean very different things: Authentication (AuthN) and Authorization (AuthZ). Understanding the difference is the first step in mastering modern identity systems.

Authentication is about who you are. It's the process of verifying a claimed identity. When you log in with a password, use your fingerprint, or tap a security key, you are authenticating. The system is confirming you are the person you claim to be.

Authorization is about what you can do. Once you're authenticated, authorization determines your permissions. Just because a system knows who you are doesn't mean you should have access to everything. Your role as an 'editor' might let you publish articles, while a 'viewer' can only read them. That's authorization in action.

In the early days of the web, every application handled its own logins. You had a separate username and password for your email, your bank, and your favorite forum. This was inefficient and insecure. A security breach at one minor service could expose credentials you used elsewhere.

The modern solution is a centralized approach called the Federated Identity Model. Instead of every application managing its own user database and login logic, they offload that responsibility to a trusted, central authority. This model splits the world into two main roles: the Identity Provider and the Service Provider.

When you want to log into a Service Provider (SP) like Salesforce, it doesn't ask for its own password. Instead, it redirects you to an Identity Provider (IdP), like Google. You log in with Google, which then tells Salesforce, "Yes, this person is who they say they are." Salesforce trusts Google and logs you in.

This entire interaction hinges on a pre-configured trust relationship between the IdP and the SP. The SP has been set up to trust identity information coming from that specific IdP, and the IdP knows it's allowed to send user data to that SP.

How does the IdP securely tell the SP about the user? It doesn't just send an email saying "Bob is okay." It sends a cryptographically signed package of information called an assertion or a token.

Inside this token are pieces of information about the user, known as claims . A claim is a statement that the IdP makes about the user. Common claims include:

• sub (Subject): A unique identifier for the user.
• name: The user's full name.
• email: The user's email address.
• groups: A list of groups the user belongs to.

The SP receives this token, verifies its signature to confirm it came from the trusted IdP and hasn't been tampered with, and then reads the claims. It can use these claims to create an account for the user on the fly or, more importantly, to make authorization decisions. If a user has a claim saying they are in the 'Admins' group, the SP knows to grant them administrative privileges.

This model—separating the concerns of authentication and authorization, and centralizing identity with a trusted provider—is the foundation of Single Sign-On (SSO). It allows users to log in once and gain access to multiple applications without re-entering their credentials, providing both convenience and a massive security upgrade over siloed logins.