When you sign into a new app using your Google or Facebook account, you're not actually giving that app your password. Instead, you're using a modern digital handshake that relies on tokens, not secrets. This process is called delegated authorization.

Think of it like giving a valet a key to your car. You wouldn't give them your master key that opens your house and safe deposit box. You give them a special key that can only start the car and maybe open the doors. It has a limited, specific purpose. If you lose the valet key, you can just invalidate that one key without having to change the locks on your house. Modern authentication works on a similar principle.

The most common framework for this process is OAuth 2.0 (Open Authorization). It's a protocol that allows an application to obtain limited access to a user account on another service. Let's walk through the most secure and common flow, called the Authorization Code Flow.

Imagine you've just downloaded a new app called "Artify" that promises to turn your photos into paintings. You want to let Artify access your photos on Google Photos without giving it your Google password. Here's what happens behind the scenes:

This multi-step dance ensures that Artify never sees your Google password. It only gets a temporary key (the Access Token) with specific permissions that you approved. This leads to two important types of tokens.

OAuth 2.0 is fantastic for authorization—determining what an app is allowed to do. But it doesn't, by itself, handle authentication—confirming who the user is. This is where OpenID Connect (OIDC) comes in.

OIDC is a simple identity layer built on top of OAuth 2.0. When you use a "Sign in with Google" button, the process is actually OIDC. It follows the same OAuth flow, but with one key addition: along with the access token, the application also receives an ID Token. This ID Token is a signed document (usually a JWT, or JSON Web Token) that contains basic profile information about you, like your name, email, and a unique identifier. This is how Artify knows it's you and can create an account for you@gmail.com.

Another protocol you'll encounter, especially in corporate or enterprise environments, is SAML (Security Assertion Markup Language). It's an older, XML-based standard for exchanging authentication and authorization data between parties. The parties involved are an Identity Provider (IdP), which manages the user's identity, and a Service Provider (SP), the application the user wants to access.

When a user tries to log into the SP, they are redirected to the IdP. After logging in, the IdP sends a digitally signed XML document, called a SAML Assertion, back to the SP. This assertion confirms the user's identity and may include other attributes, granting them access.

This whole system of passing around tokens and assertions is fundamentally more secure than sharing passwords. This security comes from a concept called tokenization and offers several key advantages:

• Limited Scope: Tokens can be issued with very specific permissions. An app might get a token that only allows it to read photos, but not delete them.
• Revocability: You can revoke an application's access at any time from your central account settings (e.g., in your Google Account). This invalidates its tokens without affecting any of your other apps or your main password.
• No Credential Exposure: The third-party app never sees, handles, or stores your actual password, massively reducing the risk if that application's database is ever breached.

By centralizing identity with trusted providers and using temporary, scoped tokens for access, these modern protocols create a more secure and manageable digital world. Simple password rotation is no longer enough because your identity is now managed through these complex, interconnected systems.