Module 6 of 8

Access Tokens, Service Tokens, and Federated Credentials

Handle humans, services, jobs, and cloud/data-platform access without treating every token the same.

100 minutes1 exercisesFree

Watch as Slides Course overviewInline lab below

Start here

Learning objectives

Compare access tokens, service tokens, and federated credentials
Design route rules for UI, API, service-to-service, and data access traffic
Understand how a central auth service can exchange trusted identity for scoped cloud credentials
Use Lake Formation as an example of why federated data access needs explicit boundaries

Different Callers Need Different Proof

A browser user opening an admin UI is not the same as a job service writing data, and neither is the same as a dashboard service reading governed tables. Central auth works best when it names the caller type and validates the right credential for that caller.

Token Decision Table

Credential	Used by	Good for	Watch out for
Access token	User-facing clients and APIs	Calling APIs on behalf of a user or client	Audience, scope, expiry, replay
Service token	Workloads and jobs	Machine-to-machine calls	Sharing tokens across services
Federated credential	Trusted service exchanging identity	Temporary cloud or data-platform access	Overbroad permissions and weak trust mapping

Federated Credentials Example

Imagine a data explorer product behind Envoy. The user is authenticated through SSO. The product asks the central auth service whether the user can access a dataset. If allowed, the platform may exchange that trusted identity for a short-lived credential that can access a cloud data service. AWS Lake Formation style governed data access is a useful example: the platform should not hand every product a broad static secret. It should map identity to scoped, auditable data access.

Route-Level Policy Shape

/ui/*: browser session or OIDC login required.
/api/*: JWT access token required with correct audience.
/internal/*: service token or workload identity required.
/data/*: user identity plus dataset authorization and optional federated credential exchange.

Do Not Treat Tokens as Passwords

Tokens should be short-lived, scoped, auditable, and rotated. A token is proof for a purpose, not a permanent identity. If every product stores the same long-lived token, central auth has not improved security.

Real world

Where this shows up

A Kubernetes platform with many internal products that should share one login and one enforcement layer
Developer portals, data tools, admin consoles, APIs, and service-to-service calls protected at the edge
Migration from product-specific auth logic to centralized policy checks without rewriting every product first

Production notes

Keep these close

Separate human and service issuers when possible
Use separate audiences for internal APIs and data-platform access
Record user, service, tenant, dataset, policy, and decision in audit logs

Common mistakes

What usually breaks

Letting UI access tokens call internal service routes directly
Using one broad service token for every job
Issuing cloud/data credentials without binding them to a specific user, service, dataset, and purpose

Security risks

Threats to watch

Confused-deputy bugs where a product uses its own broad credentials for a user who should not have access
Leaked long-lived service tokens
Federated data access without audit can hide exfiltration paths

Tradeoffs

Design choices you should be able to defend

Federated temporary credentials

Pros

Short-lived access
Better auditability
Reduced static secret exposure

Cons

More moving parts
Requires careful identity-to-permission mapping

Static product credentials

Pros

Easy to start
Few integration points

Cons

Broad blast radius
Hard revocation
Weak per-user audit

Think like an engineer

Questions to answer before shipping

Which identity is making the request: a human, a service, or a federated cloud principal?
Which check belongs at Envoy, and which check must remain inside the product domain model?
What happens when the identity provider, JWKS endpoint, or auth service is slow or unavailable?

Key terms

Vocabulary used in this module

Access token

A credential presented to call an API for a specific audience and purpose.

Service token

A machine credential used by one service or job to call another.

Federated credential

A temporary scoped credential issued after trusting another identity source.

Confused deputy

A bug where a privileged service is tricked into using its authority for a caller that should not have it.

Exercises

Practice inside the lesson

45-60 minutesBeginner to Intermediate

Classify Platform Routes

Choose the right credential type for UI, API, internal service, and data-access routes.

Create four route groups: UI, API, internal service, and data access
Choose the credential type accepted by each route group
Write issuer, audience, and expiry expectations where JWTs are used
Write when a federated credential is allowed
Write what audit fields must be recorded for data access

Recap

Key takeaways

Human, service, and federated credentials solve different problems
Data access should use scoped, auditable credentials rather than broad static secrets
Central auth should make credential type explicit per route

Related resources

Access Tokens, Service Tokens, and Federated Credentials

Learning objectives

Different Callers Need Different Proof

Token Decision Table

Federated Credentials Example

Route-Level Policy Shape

Do Not Treat Tokens as Passwords

Where this shows up

Keep these close

What usually breaks

Threats to watch

Design choices you should be able to defend

Federated temporary credentials

Static product credentials

Questions to answer before shipping

Vocabulary used in this module

Access token

Service token

Federated credential

Confused deputy

Practice inside the lesson

Classify Platform Routes

Key takeaways

Keep learning across CodersSecret

Related guides

Cheatsheets

Interactive labs

Glossary terms