OIDC Token Format
You read the oidc token format by decoding a signed three-part text string. Your identity tool sends this string after a user logs in. Engineering teams use these tokens to pass user data between web apps and servers. Teams often map broad group claims from the token straight to admin roles. When a token grants wide permissions, any user in that group can change live data. How the oidc token format works OpenID Connect builds on top of the OAuth protocol to prove who a user is. The identity t
Token Rotation + Format-Preserving Encryption: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You read the oidc token format by decoding a signed three-part text string. Your identity tool sends this string after a user logs in. Engineering teams use these tokens to pass user data between web apps and servers. Teams often map broad group claims from the token straight to admin roles. When a token grants wide permissions, any user in that group can change live data.
How the oidc token format works
OpenID Connect builds on top of the OAuth protocol to prove who a user is. The identity tool packs user facts into a JSON Web Token, or JWT. This token has three text blocks joined by dots. Each block uses Base64 encoding so web tools can send it in headers.
The first block is the header. It names the signing method and the key ID used by the identity tool. Your app reads this header first so it knows how to check the token.
The second block is the payload. It holds user claims like an email address, a user ID, and group names. It also lists the issuer name, the target app, and the token start and end times.
The third block is the cryptographic signature. The identity provider creates this block with a private key. Your app fetches the public key from the provider to check that signature. If someone edits a role claim in the payload, the signature check fails right away.
How teams check token claims at login
When a user logs in, the client app asks the identity provider for an ID token. The provider checks the user password and multi-factor prompt first. Then it builds the payload, signs the token, and sends it back to the client.
The client app or server must run several checks before trusting the token. First, it fetches the public keys from the provider endpoint and checks the signature. Next, it reads the issuer claim to confirm the token came from the right provider. Then it checks the audience claim to verify the token belongs to this specific app. Last, it checks the expiration time so old tokens cannot start a new session.
Token Rotation + Format-Preserving Encryption: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
After these checks pass, the app reads the group or role claims in the payload. Many teams map those group claims directly to database roles or server permissions. Once the session starts, the user inherits every permission attached to that local role.
What identity tokens solve and what they miss
The oidc token format solves user login across many different apps. Teams do not need to store passwords in every database or internal tool. A single login gives the app a signed proof of who the user is. When an engineer leaves the company, you revoke their account in one central place.
Still, a login token only works at the start of a session. It tells the target system who logged in and what group they belong to. It does not watch or control what the user does after the session begins.
If a token maps an engineer to a read-write database role, the token job is done. The token cannot block a bad delete statement or require approval for a schema change. It also cannot mask emails, phone numbers, card numbers, or national IDs in query results. Login tokens verify identity at the door, but they do not govern live commands in flight.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between an ID token and an access token?
An ID token proves who logged in and always uses the JSON Web Token structure. An access token grants permission to call an API and may use an opaque string instead.
Can anyone read the data inside an OIDC token?
Yes, anyone with the token can decode the header and payload because they use basic encoding. The signature stops people from changing the claims, so never put secret keys inside a payload.
How does an app know the token signature is real?
The app downloads the public key set from the identity provider discovery page. It uses that public key to verify the math behind the third part of the token.