Access Management Integration

IDToken Seal is an Identity Provider — it proves who the user is and delivers verified identity claims. It does not manage roles, permissions, or access policies. This separation is by design: authentication and authorization are distinct concerns, and organizations already have access management infrastructure they want to keep.

This page explains how IDToken Seal fits into your access management architecture.

Authentication vs. Authorization

Concern	Who handles it	What it answers
Authentication	IDToken Seal	”Who is this person?” — verified by document-derived credential + biometric
Authorization	Your access management system	”What can this person do?” — based on roles, policies, attributes

IDToken Seal’s JWT is the bridge between the two. After authentication, the JWT carries verified identity claims that your authorization layer consumes.

The JWT as Integration Point

Every successful IDToken Seal authentication produces a signed JWT containing:

• sub — the user’s tokenId (stable identifier)
• scope — the scopes the user approved (e.g., identity:name, identity:age_over_18)
• Identity claims matching the granted scopes (name, nationality, derived booleans, etc.)
• iss, aud, exp — standard JWT fields identifying the issuer, audience, and expiry

This JWT is a standard RFC 7519 token signed with ES256 (ECDSA P-256). Any system that can verify JWTs can consume IDToken Seal assertions — no proprietary SDK or protocol needed.

{
  "sub": "VDS-FR-0042-2025-00001",
  "iss": "https://auth.idtokenseal.example.com",
  "aud": "bar-le-central",
  "scope": "identity:name identity:age_over_18",
  "given_name": "Jean",
  "family_name": "Dupont",
  "age_over_18": true,
  "iat": 1711929600,
  "exp": 1711933200
}

Integration Patterns

API Gateway (Kong, Envoy, Traefik, AWS API Gateway)

The most common pattern: the API gateway validates the IDToken Seal JWT on every request and enforces access policies before traffic reaches your backend.

1. The gateway fetches IDToken Seal’s public keys from GET /jwks (cached)
2. On each request, it verifies the JWT signature and expiry
3. It checks claims against your access policies (e.g., “this endpoint requires age_over_18 = true”)
4. Valid requests are forwarded to your backend with the verified claims

RBAC / ABAC Systems

Map the tokenId (from the JWT sub claim) to local roles in your user directory:

tokenId: VDS-FR-0042-2025-00001
  → local role: "operator"
  → permissions: [read, write, approve]

IDToken Seal tells you who the user is with high assurance. Your RBAC system decides what they can do. The tokenId is the stable join key between the two systems.

For attribute-based access control (ABAC), IDToken Seal JWT claims can serve directly as policy attributes:

IDToken Seal Claim	ABAC Policy Example
age_over_18: true	Allow access to age-restricted content
nationality: "FRA"	Restrict to EU citizens for data residency
given_name, family_name	Personalize without a local user profile

Enterprise SSO (SAML / OIDC)

IDToken Seal already speaks the two standard enterprise federation protocols:

• OpenID Connect — for cloud services, SaaS platforms, and modern SSO (Google Workspace, Microsoft Entra ID, Okta, etc.)
• SAML 2.0 — for legacy enterprise systems and government portals

These protocols allow IDToken Seal to plug into existing enterprise IAM infrastructure (Active Directory, LDAP directories, identity governance platforms) without custom integration work. Your IAM system handles authorization; IDToken Seal provides the authenticated identity.

Reverse Proxy / Zero Trust (Cloudflare Access, Zscaler, Tailscale)

Zero Trust architectures authenticate every request. IDToken Seal integrates as an external IdP via OIDC:

1. Configure your Zero Trust provider to use IDToken Seal as an OIDC identity source
2. The provider redirects unauthenticated users to IDToken Seal’s authorization endpoint
3. After X.1280 authentication, the user is redirected back with an ID token
4. The Zero Trust provider enforces per-application access policies based on the verified identity

Scope-Based Consent as Authorization Ceiling

A unique property of IDToken Seal: the scopes the user approved are cryptographically bound to the authentication. The server cannot inflate them after the user’s biometric confirmation.

This means the user’s consent acts as a ceiling for authorization decisions:

Registered scopes (service maximum):    identity:full
  ∩ Requested scopes (this session):    identity:name, identity:age_over_18
    ∩ Granted scopes (user approved):   identity:name
      → JWT contains: given_name, family_name only

Your access management system operates within this ceiling. Even if your RBAC policy says a user has full access, the JWT will only contain the claims the user chose to share. This gives users privacy guarantees enforced by cryptography, not just policy.

See Selective Disclosure for the full scope system and available claims.

Typical Architecture

The key insight: IDToken Seal replaces the “who are you?” step with high-assurance, government-backed identity — but leaves the “what can you do?” step entirely to your existing infrastructure. No vendor lock-in, no proprietary authorization model.

Summary

Question	Answer
Does IDToken Seal replace my IAM system?	No — it replaces the authentication layer (passwords, FIDO) with stronger identity proof
How does my system consume IDToken Seal?	Via standard JWT, OIDC, or SAML — no proprietary integration
What’s the join key for local roles?	The tokenId in the JWT sub claim — stable per enrollment
Can users limit what my system sees?	Yes — scope-based consent is cryptographically enforced
Do I need to store user data?	Only if you want to — IDToken Seal delivers identity on each login. Local role mappings (tokenId → role) are optional