Vercel OIDC-Token unterstützen jetzt benutzerdefinierte Audiences
Vercel erweitert seinen OIDC-Issuer unter `oidc.vercel.com` um einen Token-Exchange-Dienst, der es Deployments erlaubt, OIDC-Tokens mit einem beliebigen, provider-spezifischen `aud`-Claim anzufordern. Bislang wurden Vercel-OIDC-Tokens stets mit einer fixen Audience ausgestellt – dem Pfad `https://vercel.com/{owner}` –, was zwar von den meisten Cloud-Anbietern akzeptiert wird, aber ein Sicherheitsrisiko darstellt: Ein gestohlenes Token wäre prinzipiell gegen jeden Dienst wiederverwendbar, der dieselbe Audience akzeptiert. Der neue Exchange-Endpunkt nimmt ein gültig signiertes Vercel-OIDC-Token entgegen und stellt ein neues Token aus, das mit demselben Schlüssel signiert ist, jedoch einen aktualisierten `aud`-Claim für den gewünschten Downstream-Dienst trägt. Dabei bleiben alle ursprünglichen Claims – Projekt, Umgebung, Owner und Ablaufzeit – erhalten. Zusätzlich wird ein `act`-Claim (Actor) eingefügt, der die ursprüngliche Audience und den Ausstellungszeitpunkt des Ausgangstokens dokumentiert und so eine nachvollziehbare Delegationskette erzeugt. Optional kann ein `jti`-Parameter (JWT ID) übergeben werden, um das ausgetauschte Token für Audit- und Tracing-Zwecke eindeutig zu identifizieren. Der Exchange-Endpunkt sowie der zugehörige Signing-Key sind über alle Vercel-Regionen repliziert, sodass die Latenz unabhängig vom Deployment-Standort gering bleibt.
- Fixe Original-Audience war `https://vercel.com/{owner}` – der Exchange-Dienst ersetzt diesen Wert durch eine frei wählbare Downstream-Audience.
- Der `act`-Claim im ausgetauschten Token enthält die ursprüngliche Audience und den `iat`-Zeitstempel des Eingangstokens, was eine lückenlose Delegationskette für Audits ermöglicht.
- Optionaler `jti`-Parameter (JWT ID) erlaubt die Vergabe einer eindeutigen Token-ID, z. B. zur Korrelation mit nachgelagerten API-Aufrufen in Log-Systemen.
- Öffentliche JWKS-Schlüssel für die Verifikation der ausgetauschten Tokens sind unter `https://oidc.vercel.com/{owner}/.well-known/jwks` abrufbar.
- Signing-Key und Exchange-Endpunkt sind über alle Vercel-Regionen repliziert – geringer Latenz-Overhead unabhängig vom Deployment-Standort.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
- LAUNCHvercel.com1w
Vercel erklärt langlebigen statischen Credentials den Krieg
- LAUNCHvercel.com2w
Vercel Connect führt Enterprise-Managed Authorization in Public Beta ein
- LAUNCHvercel.com1mo
Vercel Connect öffnet Connector-Verzeichnis für eigene Service-Einreichungen
- LAUNCHvercel.com2w
Vercel Connect unterstützt jetzt Secure Compute für IP-Allowlist-Provider
Vercel OIDC-Token unterstützen jetzt benutzerdefinierte Audiences
Vercel erweitert seinen OIDC-Issuer unter `oidc.vercel.com` um einen Token-Exchange-Dienst, der es Deployments erlaubt, OIDC-Tokens mit einem beliebigen, provider-spezifischen `aud`-Claim anzufordern. Bislang wurden Vercel-OIDC-Tokens stets mit einer fixen Audience ausgestellt – dem Pfad `https://vercel.com/{owner}` –, was zwar von den meisten Cloud-Anbietern akzeptiert wird, aber ein Sicherheitsrisiko darstellt: Ein gestohlenes Token wäre prinzipiell gegen jeden Dienst wiederverwendbar, der dieselbe Audience akzeptiert. Der neue Exchange-Endpunkt nimmt ein gültig signiertes Vercel-OIDC-Token entgegen und stellt ein neues Token aus, das mit demselben Schlüssel signiert ist, jedoch einen aktualisierten `aud`-Claim für den gewünschten Downstream-Dienst trägt. Dabei bleiben alle ursprünglichen Claims – Projekt, Umgebung, Owner und Ablaufzeit – erhalten. Zusätzlich wird ein `act`-Claim (Actor) eingefügt, der die ursprüngliche Audience und den Ausstellungszeitpunkt des Ausgangstokens dokumentiert und so eine nachvollziehbare Delegationskette erzeugt. Optional kann ein `jti`-Parameter (JWT ID) übergeben werden, um das ausgetauschte Token für Audit- und Tracing-Zwecke eindeutig zu identifizieren. Der Exchange-Endpunkt sowie der zugehörige Signing-Key sind über alle Vercel-Regionen repliziert, sodass die Latenz unabhängig vom Deployment-Standort gering bleibt.
- Fixe Original-Audience war `https://vercel.com/{owner}` – der Exchange-Dienst ersetzt diesen Wert durch eine frei wählbare Downstream-Audience.
- Der `act`-Claim im ausgetauschten Token enthält die ursprüngliche Audience und den `iat`-Zeitstempel des Eingangstokens, was eine lückenlose Delegationskette für Audits ermöglicht.
- Optionaler `jti`-Parameter (JWT ID) erlaubt die Vergabe einer eindeutigen Token-ID, z. B. zur Korrelation mit nachgelagerten API-Aufrufen in Log-Systemen.
- Öffentliche JWKS-Schlüssel für die Verifikation der ausgetauschten Tokens sind unter `https://oidc.vercel.com/{owner}/.well-known/jwks` abrufbar.
- Signing-Key und Exchange-Endpunkt sind über alle Vercel-Regionen repliziert – geringer Latenz-Overhead unabhängig vom Deployment-Standort.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
- LAUNCHvercel.com1w
Vercel erklärt langlebigen statischen Credentials den Krieg
- LAUNCHvercel.com2w
Vercel Connect führt Enterprise-Managed Authorization in Public Beta ein
- LAUNCHvercel.com1mo
Vercel Connect öffnet Connector-Verzeichnis für eigene Service-Einreichungen
- LAUNCHvercel.com2w
Vercel Connect unterstützt jetzt Secure Compute für IP-Allowlist-Provider