Authentication and Authorization Concepts and Workflow

Select

Part One Session

‣

The Mystery Behind Sign In with Google

We’ve all encountered a sign-in page that says "Sign in with your Google account," but what does that actually mean? It's like you click on it, and suddenly, you have an account on that platform with your name and some basic information about you, even though you didn’t create an account using a username/email and password. Today, we’ll explore exactly what happens behind the scenes.

There are two key terms we need to clarify the difference between identity verification and authentication , and we’ll be using the latter one quite often.

Who Are You Again? The Battle of Identity vs Authentication

Identity verification occurs during account creation, often using phone numbers or recovery emails to confirm you’re a real person. Afterwards, authentication uses your username and password each time you log in it verify that a person is who they claim to be.

Demystifying Sign-In

Google: Sign in with your Google account, no password needed.
IdP: Use a trusted provider (e.g., Microsoft, Okta) to log in securely.
Passkey: Passwordless login via fingerprint or face ID.
Email: Sign in with a magic link or email password.
Phone: Verify with a OTP code sent to your phone.

Deep Dive into Identity Providers

Single Sign-On (SSO) allows users to log in once with one set of credentials to access multiple applications or systems. It simplifies authentication while improving security and user experience, example You log into your Google account once, Then you can access Gmail, YouTube, Google Drive, and other Google services without logging in again.

An Identity Provider (IdP) is a trusted service that authenticates users and provides identity information to other applications or services. It enables Single Sign-On (SSO) by allowing users to log in once and access multiple systems securely.

The Service Provider (SP) trusts the Identity Provider to verify the user’s identity and grants access based on the authentication result.

Seamless Sign-Ins with Identity Power

User selects Continue with Google and the website redirects to Google’s login page.
User enters their Google credentials or uses biometrics to authenticate with Google.
Google verifies the user’s identity and creates a secure authentication token.
Google sends the token back to the user's browser via a redirect URL.
The website validates the token to confirm the user’s identity.
The browser then redirects (or auto-submits) the token to the website's backend server
The user is granted access without sharing their password with the website.

One Login to Rule Them All

If we repeatedly implement the same login flow across multiple platforms using the same Identity Provider, we achieve what's known as federated identity, that allows users to access multiple systems or applications using a single digital identity managed by a trusted external identity provider.

SSO is built on the concept of federated identity, which means SSO allows access to multiple applications within a single organization, while FIM enables access across different organizations or domains.

Exploring Authentication Protocols

Two main authentication protocols are widely used: Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). SAML, which is XML-based, is supported by many enterprise applications such as Office 365, Azure Active Directory, Slack, and Zoom for Single Sign-On. OIDC, built on OAuth 2.0 and using JSON Web Tokens (JWT), is commonly used by providers like Google to enable authentication for services like Gmail and YouTube. Both protocols serve different needs but often coexist across platforms.

If a service provider (SP) uses SAML for authentication, you can configure Google as the Identity Provider (IdP) to support SAML-based Single Sign-On.

Conversely, if a third-party IdP uses SAML, Google can act as the SAML service provider (SP) to accept SAML tokens from that IdP for authentication.

Inside the Heart of SAML

This SAML Assertion declares that user@example.com was authenticated by https://idp.example.com at a specific time using a password-protected method. It includes validity constraints (NotBefore / NotOnOrAfter) and is used by the Service Provider to trust the user's identity.

The SAML Login Journey

User tries to access Gmail (the Service Provider).
Gmail sends a SAML Authentication Request to the user's browser.
The browser redirects the user to the Identity Provider (IdP) such as Okta or OneLogin.
The user enters their username and password at the IdP.
The IdP verifies the credentials against its database.
If credentials are correct, the IdP creates a SAML Response (an XML document) containing user info and access rights.
The IdP digitally signs this response by, Computing a hash of the SAML assertion, then Encrypting the hash with its private key to create a digital signature.
The IdP sends the signed SAML assertion back to the browser via redirect.
The browser forwards the signed assertion to Gmail (SP).
Gmail verifies the digital signature by, Using the IdP’s public key that is related to this SP to decrypt the signature and retrieve the original hash, then Computing its own hash of the received assertion after that Comparing both hashes; if they match, the assertion is trusted and untampered.
Upon successful verification, Gmail grants access to the user.
If the user accesses another application using the same IdP, the IdP recognizes the existing session and creates a new SAML assertion without requiring login again (SSO).
After login, the Service Provider manages the user session using cookies or tokens, The SAML assertion is not stored persistently in the browser; it is temporary during login.

Ensures SAML Trust in Single Sign-On

The user submits login credentials to the Identity Provider (IdP), which validates them.
If valid, the IdP creates a SAML Response (an XML document) containing the user’s identity, attributes, and access rights.
To ensure trust, the IdP digitally signs the SAML Response by, Computing a hash of the assertion, Encrypting this hash with its private key to create a tamper-proof digital signature.
The signed SAML Response is sent back to the user’s browser via an HTTP redirect.
The browser forwards the signed response to Gmail (the Service Provider), which uses it to verify the user’s identity.
Gmail verifies the signature by, Using the IdP’s public key to decrypt the signature and get the original hash, Computing its own hash of the assertion, Comparing both hashes; if they match, Gmail trusts the assertion and grants access.

IdP Shares Its Public Key with the SP

The IdP generates a key pair (private and public keys) during initial setup. It then shares the public key, typically in X.509 format, with the Service Provider in advance so the SP can verify the digital signatures on future SAML assertions.

Example of a public key (X.509 certificate format used in SAML), as the X.509 is a standard that defines the format of public key certificates.

<ds:X509Certificate>
MIIDdzCCAl+gAwIBAgIEbDbl+jANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJV...
</ds:X509Certificate>

If App1 registers their app with IdP, and App2 also registers separately, they each have their own separate trust relationship and key pairs. IdP doesn’t give everyone the same key. Each SP like App1 or App2 provides its own metadata, which can include their public key for encrypted assertions, and signs assertions with its own key.

So if App1 private key gets leaked, only App1 setup is compromised, not App2

Now, we will discuss session-based authentication and JWT-based authentication, both of which are used to manage user sessions.

Beyond Cookies

Cookie is a small piece of data that a website stores on your browser to remember information about you, that stores a session ID created by the server.

The server saves this ID and sends it inside a cookie with security flags like HttpOnly and Secure.

The browser sends the cookie on each request so the server can identify the session.

Set-Cookie: session_id=abc123xyz; HttpOnly; Secure; Path=/; SameSite=Strict

HttpOnly: Prevents potentially malicious JavaScript attempting to access a cookie set by your website, protecting it from XSS attacks.
Secure: Ensures the cookie is only sent over HTTPS, not HTTP, protecting it during transmission.

Browser’s Secret Cookie Unlocks Seamless Single Sign-On

When you first authenticate with an IdP, a session cookie is saved in your browser. This cookie stores information about your authentication session with that specific IdP.
Later, whenever you access another app that uses the same IdP, your browser automatically sends that session cookie back to the IdP. This lets the IdP know that you've already authenticated.
The IdP checks the cookie and sees that you're already logged in, so it doesn't ask you to enter your credentials (email and password) again.

They can be either session cookies (deleted when browser closes) or persistent cookies (stored with an expiration date and kept after closing the browser). So cookies can persist too, not always deleted.

The JWT Journey

A JWT (JSON Web Token) is a token used to securely transmit identity and claims between parties.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. 
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNjg4MDA4MDAwfQ. 
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Demystifying JWT Signatures

Header Contains metadata about the token, such as the type of token (JWT) and the signing algorithm (e.g., HS256, RS256).

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload Contains the claims (statements) about an entity (typically the user) and additional data. This is where you'd find information like user ID, roles, expiration time, etc.

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1688008000
}

Signature Used to verify that the sender of the JWT is who it says it is and to ensure that the message hasn't been tampered with, as all three parts are Base64Url-encoded and joined by dots (.).

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

How JWT Signs Trust

The signature is created by hashing the Base64Url-encoded header and payload using a secret key, known only to the server.

The server signs and later verifies the JWT using this same key.

To verify, the server reconstructs the signing input (header.payload), hashes it with the secret, and compares it with the received signature.

How Local Storage Remembers You

Local Storage is a web browser feature that allows websites to store data locally on the user’s device, It provides a way to save key-value pairs persistently, even after the browser is closed and reopened, Data in local storage as JWT is specific to the domain (website)

JWT persist even after closing the browser unless explicitly cleared. They are not automatically deleted and can be reused until expired or removed by JavaScript or the user.

Aspect	JWT	Cookies
`Storage`	`localStorage, sessionStorage, or cookie`	`Browser-managed cookie store`
`Sent with requests`	`Manually added to headers (e.g., Authorization)` Instead, your web app’s code (JavaScript) must explicitly read the token from storage and attach it to the request headers, usually in the `Authorization` header like:`Authorization: Bearer <JWT-token>`	`Automatically sent by browser`
`Best use case`	`APIs, mobile apps`	`Traditional web apps, server sessions`

So far, we've covered SAML authentication, cookies, and JWTs. Next, we'll move on to the concept of authorization, starting with OAuth 2.0. After that, we'll dive into OpenID Connect (OIDC), since OIDC is built on top of OAuth 2.0 making it essential to understand OAuth first.

The Magic of OAuth 2.0

Authorization is the process of determining what actions a user is allowed to perform after they’ve been authenticated, It controls access to resources like APIs, data, or features based on roles, scopes, or permissions. Authorization Server is the system that handles login, permissions, and token generation in OAuth, It verifies the user’s identity and issues access tokens to apps based on user consent.

Designed to securely delegate access to resources without sharing passwords, Allows third-party apps to access specific data with user consent, as users can revoke access at any time.

The Era Before OAuth

Users shared their username and password with third-party apps, this method was insecure and is discouraged now, it is still seen in some legacy finance apps scraping bank data.

The Power of OAuth

OAuth allows one application (the client) to access another application's data on behalf of a user, without the user sharing their username and password.

Instead of credentials, the client uses a token (access token) to access limited data with permissions granted by the user.

This token restricts what the second application can do e.g., it can read your Google Drive files but not your emails, based on the token’s scope (permissions).

The token can be revoked anytime, stopping access instantly, so the user controls the permissions.

Speak the Language of Secure Access

Resource Owner: The user who owns the data (you).
Client: The third-party app requesting access.
Authorization Server: The server that authenticates the user and issues tokens (e.g., Google login).
Resource Server: The server hosting the protected data (e.g., Google Calendar).
Redirect URI (Callback URL): URL where the authorization server sends the user back after login/consent.
Response Type: Type of token or code returned (e.g., authorization code).
Scope: Defines what permissions the client is requesting (e.g., read calendar, access profile).
Consent: The user’s approval or denial of requested permissions.
Client ID: Public identifier of the client app.
Client Secret: Private secret known only to the client and authorization server, used to authenticate the client during token exchange.
Authorization Code: Temporary code used to obtain access token.
Access Token: Token the client uses to access the resource server.

How Apps Introduce Themselves with Client ID and Redirect URI

Before users ever log in, the app owner (Notion) goes to the Authorization Server’s website (like Google Developer Console) and says, I want to create a new app that uses your login, Google then gives the app a unique Client ID and Client Secret, The app owner also tells Google: After login, send users back to this URL (the Redirect URI).
Now, the app has these 3 important pieces (Client ID, Redirect URI, and Client Secret) saved inside its code or configuration.
When a user wants to log in, the app builds a special login link with, Its Client ID, The Redirect URI, The permissions it wants (scope)

A Walk Through the OAuth Flow

You want to link your Notion account to access information from your Google Calendar, so your Notion (client) asks to access your Google Calendar Information.
Client redirects the user to the Authorization Server (google) with, Client ID, Redirect URI (callback URL), Requested scopes (permissions)
User logs into the Authorization Server by entering credentials (email/password).
User is shown a consent screen detailing what data the app will access (e.g., calendar, profile).
If user consents, Authorization Server sends a temporary authorization code back to the client (via the redirect URI) tied to that specific user and their consent.
Client Backend exchanges the authorization code for an access token by sending it to the Authorization Server with the client ID and client secret, as a Direct request to the client server makes backchannel request to Authorization Server
Authorization Server verifies the authorization code, then issues the access token, as a direct request the Authorization Server responds to client server
The client uses the access token to request data from the Resource Server (e.g., Google Calendar API) on behalf of the user, as a direct request the client server calls Resource Server APIs)
Resource Server responds with requested data according to the permissions granted, as a direct request the Resource Server sends data to client server
The access token is opaque to the client just a string proving authorization.

Key Insights You Can’t Miss

Sometimes the Authorization Server and Resource Server are the same (e.g., Google).
The client secret must be kept confidential to prevent unauthorized access.
OAuth separates authentication (login) from authorization (access control).
The access token has a limited lifespan and can be revoked by the user or authorization server at any time.
Access tokens can expire.
Refresh tokens allow getting a new access token without re-authentication.

The Role of OIDC in Modern Login

OIDC is built on top of OAuth 2.0 to add user authentication, It enables the client application to, Know who the user is and Authenticate the user directly via an Identity Provider, OIDC allows the Authorization Server to become an Identity Provider (IdP) if it supports OIDC.

How OIDC Turns Access into Identity

An Authorization Server that supports OIDC becomes an Identity Provider, It doesn’t just issue Access Tokens, but also returns an ID Token to give user identity info, This allows the client to log in the user without asking for a username or password again.

OIDC enables SSO, allowing the user to authenticate once and access multiple apps without re-logging in, This is done using the ID Token, which carries the user's identity info across sessions.

How OAuth and OIDC Work Together

User wants to login, so the client app redirects the user to the Authorization Server with: Client ID, Redirect URI, Scope=openid
In OIDC, the scope includes openid to signal the need for authentication
The user logs in and gives consent, Authorization Server returns an Authorization Code (via browser redirect to Redirect URI)
The client app exchanges the Authorization Code (via a secure backend-to-backend call to the token endpoint) for: Access Token (used to access APIs/resources) and ID Token (a JWT used to authenticate the user)
The ID Token is received by the client from the token endpoint, not via browser redirect, it’s part of the token response (JSON payload)
The client app verifies the ID Token checks signature, iss, aud, and exp
The client parses the JWT payload to extract claims (e.g., sub, name, email, etc.)
The client creates a session for the user, storing info in session cookies
User is now logged in; the app considers the user authenticated based on a valid ID Token
User won’t need to re-authenticate again during the session (SSO behavior)

JWT Verification in OIDC

The JWKS (JSON Web Key Set) endpoint is a publicly accessible URL provided by the Identity Provider (IdP) that exposes a set of public keys in JSON format. https://example-idp.com/.well-known/jwks.json

RS256 uses a private key held securely by the Identity Provider (IdP) to sign the JWT. The client or service validating the token uses the public key (which the IdP publishes openly, e.g., via JWKS endpoint) to verify the signature. This means the private key never leaves the IdP, enhancing security.

HS256 uses a shared secret key that both the IdP and the client possess. This same secret is used to sign and verify the JWT. If the secret leaks, anyone with it can create valid tokens, which is why it is less secure.

What You Really Pay for Google Sign-In at Scale

Pricing is based on Monthly Active Users (MAUs) first 50,000 MAUs are free; beyond that, tiered pricing applies (as low as $0.0025 per MAU).

Phone and multi-factor authentication are charged per SMS, with rates varying by country (first 10 SMS/day are free).

Use the Google Cloud Pricing Calculator to forecast and monitor usage and costs.

Understanding Google Cloud Identity, Google Workspace, and OAuth 2.0 App Registration in Google Cloud Console

Google Identity Provider allows organizations to use Google accounts for Single Sign-On (SSO) into third-party apps. It supports authentication protocols like SAML and OpenID Connect (OIDC). Configuration is done through the Google Admin Console, not the Google Cloud Console. In this setup, Google acts as the Identity Provider (IdP), and the third-party app is the Service Provider (SP). Unlike developer apps, Google doesn’t issue a client_id or client_secret here the SP manages those. This setup is intended for enterprise authentication, not for building custom apps.

The Admin Console is the central dashboard where admins manage Google Workspace services (like Gmail, Drive, Calendar), user accounts, groups, security policies, and app integrations.

Google Workspace bundles the core identity management of Google Cloud Identity and adds the rich suite of productivity applications. When you subscribe to Workspace, you get the IdP functionality inherently, and you manage it all through the same Google Admin Console. You're leveraging the underlying Google Cloud Identity for your users, but gaining the full collaborative ecosystem.

An employee uses Google Docs to collaborate in real time with teammates, sharing documents via Google Drive and leaving comments. They schedule meetings through Google Calendar, all under the same secure Google Workspace identity.

When your application (the client) needs to access Google's own services (like Google Calendar API, Google Drive API these act as resource servers) on behalf of a user, you configure access in the Google Cloud Console, which is part of the Google Cloud Platform (GCP).

You'll perform app registration by creating an OAuth 2.0 Client ID within a GCP project. This client ID identifies your app

You'll define the permissions your app needs by specifying OAuth scopes (e.g., https://www.googleapis.com/auth/calendar). The Google Calendar API (the resource server) defines what these scopes grant access to. Google's Authorization Server (part of Google Identity Services) handles the user consent flow: it prompts the user to consent to your app accessing their data with those specified permissions, and if approved, it issues the necessary tokens (authorization code, then access token/refresh token). The Google Cloud Console is the management interface for Google Cloud Platform (GCP). Within the Cloud Console, you provision and manage a vast array of GCP services like Compute Engine (for VMs), Cloud SQL/Cloud Spanner (for databases), Cloud Storage, and many more.

admin.google.com

is for organization-wide identity and policy management, mainly used by IT administrators, Used with Google Workspace or Cloud Identity

console.cloud.google.com

is for managing cloud infrastructure and services, mainly used by developers, DevOps, and engineers.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_abc123" IssueInstant="2025-07-10T20:00:00Z" Version="2.0"> <saml:Issuer>https://idp.example.com</saml:Issuer> <saml:Subject> <saml:NameID>user@example.com</saml:NameID> </saml:Subject> <saml:Conditions NotBefore="2025-07-10T20:00:00Z" NotOnOrAfter="2025-07-10T21:00:00Z"/> <saml:AuthnStatement AuthnInstant="2025-07-10T20:00:00Z"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion>

Authentication and Authorization Concepts and Workflow

Table of Contents:

The Mystery Behind Sign In with Google

Who Are You Again? The Battle of Identity vs Authentication

Demystifying Sign-In

Deep Dive into Identity Providers

Seamless Sign-Ins with Identity Power

One Login to Rule Them All

Exploring Authentication Protocols

Inside the Heart of SAML

The SAML Login Journey

Ensures SAML Trust in Single Sign-On

IdP Shares Its Public Key with the SP

Beyond Cookies

Browser’s Secret Cookie Unlocks Seamless Single Sign-On

The JWT Journey

Demystifying JWT Signatures

How JWT Signs Trust

How Local Storage Remembers You

The Magic of OAuth 2.0

The Era Before OAuth

The Power of OAuth

Speak the Language of Secure Access

How Apps Introduce Themselves with Client ID and Redirect URI

A Walk Through the OAuth Flow

Key Insights You Can’t Miss

The Role of OIDC in Modern Login

How OIDC Turns Access into Identity

How OAuth and OIDC Work Together

JWT Verification in OIDC

What You Really Pay for Google Sign-In at Scale

Understanding Google Cloud Identity, Google Workspace, and OAuth 2.0 App Registration in Google Cloud Console

Authentication and Authorization Concepts and Workflow

Table of Contents:

The Mystery Behind Sign In with Google

Who Are You Again? The Battle of Identity vs Authentication

Demystifying Sign-In

Deep Dive into Identity Providers

Seamless Sign-Ins with Identity Power

One Login to Rule Them All

Exploring Authentication Protocols

Inside the Heart of SAML

The SAML Login Journey

Ensures SAML Trust in Single Sign-On

IdP Shares Its Public Key with the SP

Beyond Cookies

Browser’s Secret Cookie Unlocks Seamless Single Sign-On

The JWT Journey

Demystifying JWT Signatures

How JWT Signs Trust

How Local Storage Remembers You

The Magic of OAuth 2.0

The Era Before OAuth

The Power of OAuth

Speak the Language of Secure Access

How Apps Introduce Themselves with Client ID and Redirect URI

A Walk Through the OAuth Flow

Key Insights You Can’t Miss

The Role of OIDC in Modern Login

How OIDC Turns Access into Identity

How OAuth and OIDC Work Together

JWT Verification in OIDC

What You Really Pay for Google Sign-In at Scale

Understanding Google Cloud Identity, Google Workspace, and OAuth 2.0 App Registration in Google Cloud Console