OIDC Audience Claim
The oidc audience claim names the exact app or service that should accept a login token. You set this value in your identity provider and check it in your target service. Teams use this claim to stop token reuse across separate tools. Without strict checks, a token meant for a test app might work on a production database. Broad audience values give one token too much reach across your stack. How the oidc audience claim works OpenID Connect uses JSON Web Tokens to prove who a user is. When a
K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The oidc audience claim names the exact app or service that should accept a login token. You set this value in your identity provider and check it in your target service.
Teams use this claim to stop token reuse across separate tools. Without strict checks, a token meant for a test app might work on a production database. Broad audience values give one token too much reach across your stack.
How the oidc audience claim works
OpenID Connect uses JSON Web Tokens to prove who a user is. When a person or service logs in, the identity provider creates a signed token. That token holds several fields called claims.
The issuer claim shows who made the token. The subject claim names the user or workload. The audience claim lists the exact recipients that should trust the token.
During login, the client asks the identity provider for a token aimed at a target service. The identity provider checks the user role and puts the target identifier into the audience field. It then signs the token with its private key.
Next, the client sends this token to the target service or database. The receiving service fetches the public keys from the identity provider to check the signature. It also reads the expiration time to make sure the token is still fresh.
Then the service checks the audience field against its own unique name. If the audience matches, the service lets the request in. If the name is missing or wrong, the service rejects the token right away.
Setting up strict audience checks across services
Good token hygiene starts with unique names for every backend service and cluster. Teams often assign a clear URI or client ID to each database and API. Each app should only accept its own name in the audience field.
Problems start when teams share one client ID across many internal tools. If an attacker steals a token from a weak web app, they can replay it elsewhere. Any other service that trusts that same audience value will accept the stolen token.
K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Multi-service tokens also create risk when an audience field holds a long list of targets. Every listed target must trust all other targets in that list. Keeping one target per token limits the blast radius if a token leaks.
Teams should also separate human login tokens from machine workload tokens. A web client needs a different audience identifier than a background job runner. This split stops someone from using a browser token to run backend scripts.
What audience checks solve and what they leave open
Strict audience checks solve the confused deputy problem during login. They prove that the identity provider made the token for that exact database or server. They also stop attackers from moving sideways with a token meant for another app.
Still, the audience claim only works at the front door during login. Once the service accepts the token, the check is over. The claim says who can log in, not what commands they can run next.
A valid token with the right audience still grants the full permissions of the mapped role. If that role can drop tables or read secret rows, the token allows it. The token itself cannot block bad queries or mask sensitive fields like emails and card numbers.
Identity providers also cannot see what happens inside the session after login finishes. They log the token creation, not the SQL statements or shell commands that follow. Teams still need a way to inspect live queries and mask private data in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between the issuer and audience claims?
The issuer claim identifies the identity provider that created and signed the token. The audience claim identifies the specific app or service that should accept and use that token.
Can an OIDC token have more than one audience value?
Yes, the audience field can hold a single string or a list of strings. Still, using one target per token is safer because it stops token replay between services.
What happens if a service skips the audience check?
If a service only checks the signature, it will accept any token from that identity provider. A user could take a token from a low-risk app and log into a sensitive system.