Table of Contents:
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
<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>
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
andpassword
at the IdP. - The IdP
verifies
the credentials against its database. - If credentials are
correct
, the IdP creates aSAML Response
(an XML document) containing user info and access rights. - The IdP
digitally signs this response
by, Computing ahash
of the SAML assertion, thenEncrypting the hash with its private key
to create a digital signature. - The IdP sends the
signed SAML
assertion back to thebrowser
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 thisSP
todecrypt
the signature andretrieve the original hash
, thenComputing
its own hash of the received assertion after thatComparing
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 thesame IdP
, theIdP recognizes
the existing session andcreates a new SAML assertion
without requiringlogin again
(SSO). - After login, the Service Provider manages the user session using
cookies
ortokens
, The SAML assertion isnot 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 ahash
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 toverify
the user’s identity. - Gmail verifies the signature by, Using the
IdP’s
public key
todecrypt
thesignature and get the original hash
, Computing itsown hash
of theassertion
,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
: Preventspotentially malicious JavaScript
attempting to access a cookie set by your website, protecting it fromXSS
attacks.Secure
: Ensures the cookie is only sent overHTTPS
, notHTTP
, protecting it during transmission.
Browser’s Secret Cookie Unlocks Seamless Single Sign-On
- When you first
authenticate with an IdP
, asession 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
andClient Secret
, The app owner also tells Google: After login, send users back to this URL (theRedirect 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
, TheRedirect URI
, Thepermissions 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 anaccess 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 theaccess 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
andResource 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 tokenwithout 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 theAuthorization Server
with:Client ID
,Redirect URI
,Scope=openid
- In OIDC, the scope includes
openid
to signal the need forauthentication
- The user logs in and gives consent, Authorization Server returns an
Authorization Code
(via browser redirect toRedirect URI
) - The
client app
exchanges theAuthorization Code
(via a secure backend-to-backend call to the token endpoint) for:Access Token
(used to access APIs/resources) andID 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 theID Token
checkssignature
,iss
,aud
, andexp
- 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 insession 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 AP
I (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.