Schedule icon
Request icon
Script icon
OutputValues icon
If icon
SlackIncomingWebhook icon
Fail icon
Log icon

Gate OIDC Signing-Key Rollovers with a Pinned JWKS

Check a pinned OIDC issuer and JWKS for required signing keys. Save evidence, alert Slack, and stop unsafe releases.

Categories
CloudInfrastructure

Check OpenID Connect signing-key overlap before a client rollout or planned key retirement. The expected issuer, JWKS URL, and required key IDs must come from an independent, trusted configuration. This does not cryptographically verify a JWT, and PASS cannot guarantee future key availability.

How it works

  1. get_discovery reads the configured OIDC discovery document over HTTPS.
  2. get_key_set reads the separately approved JWKS endpoint over HTTPS. Both requests reject redirects. The Node checker rejects JSON documents over 1 MiB after retrieval; HTTP Request uses its default response limit.
  3. assess_key_overlap checks the exact issuer and JWKS URL values, the public signing-key shapes, optional JOSE signing-algorithm compatibility, key-ID uniqueness, and required key IDs. It writes a complete JSON report for both PASS and BLOCK decisions.
  4. publish_report exposes the verdict and report URI.
  5. key_overlap_gate alerts Slack and fails the execution on BLOCK. Malformed JSON, invalid configuration, and network failures fail the execution before the gate; they never produce PASS.

What you get

  • A PASS/BLOCK preflight to use as a dependency of identity-aware releases.
  • A JSON report with present and missing key IDs, counts, and reasons.
  • Slack alerts for completed BLOCK decisions and a failed execution.

Who it's for

  • Identity engineers managing issuer signing-key rotation.
  • Platform teams deploying services that verify OIDC ID tokens.
  • Security engineers reviewing SSO and API authentication changes.

Why orchestrate this with Kestra

Make signer overlap checks repeatable before deployment or on a schedule. The saved report gives operators evidence rather than a green HTTP probe. Kestra can block later tasks and notify responders about a failed preflight.

Prerequisites

  • A Kestra worker with outbound HTTPS access to both public OIDC endpoints.
  • The Node Script and Slack notification plugins.
  • An independently approved issuer, JWKS endpoint URL, and list of key IDs.
  • A Slack webhook to receive completed BLOCK alerts.

Secrets

  • SLACK_WEBHOOK_URL: incoming Slack webhook for a blocked preflight. No OIDC private keys or client credentials are required.

Quick start

  1. Create SLACK_WEBHOOK_URL as a Kestra secret.
  2. Set discovery_url, expected_issuer, jwks_url, and required_kids. Get required_kids from a reviewed application rollout manifest or an approved list of key IDs, not from the live JWKS being checked.
  3. Run manually for a healthy issuer. Check outputs.publish_report.values.report_uri for the full JSON report.
  4. Repeat with a missing required_kids entry. Confirm the report is BLOCK, Slack receives an alert, and the execution fails.
  5. Enable the six-hour schedule only after setting valid defaults for required_kids and testing both paths. Defaults for the public Google endpoints are examples; use your own identity provider in production.

How to extend

  • Compare the approved issuer's JWT signature algorithms with a client allowlist as part of a separate token-validation test.
  • Add a two-sample grace period before paging during planned rotations.
  • Persist reports for a history of signing-key overlap across releases.

Limits

  • This verifies only public key metadata and key-ID availability at one point.
  • It does not prove key possession, verify signatures, test token expiry, check revocation, or fetch a token for an end-to-end sign-in test.
  • Signed JWTs can also be issued without a kid; this workflow requires IDs because it explicitly gates a key-ID based rotation strategy.
  • An operator must update required_kids after a reviewed retirement; copying the current JWKS into the trusted manifest defeats the gate.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.