Phase II: full IDP surface (JWKS, refresh tokens, asymmetric/ES256, auth.idp module)

[intel352]

v0.3.0 shipped the minimal HS256 session-issue primitive (step.auth_jwt_issue) per ADR-0002 — sufficient for symmetric-secret consumers + the bootstrap demo. Deferred to Phase II:

• auth.idp module + step.auth_jwt_issue asymmetric (ES256/RS256) signing with key rotation.
• step.auth_jwks_serve — /.well-known/jwks.json for multi-service verification.
• Refresh tokens (step.auth_refresh_token_issue / _verify).

Trigger: a consumer needing cross-service asymmetric JWT verification (the HS256 shared-secret model requires every validator to share the secret).

Refs: ADR-0002, docs/plans/2026-06-02-auth-bootstrap-redeem-design.md §Scope, prior docs/plans/2026-05-17-admin-bootstrap-and-passkey-upgrade-design.md §Phase II.

[intel352]

Resolved — cross-service asymmetric auth supported by reuse (no bespoke IDP)

Phase II's needs (cross-service asymmetric ES256 verification · refresh · validation · external IDPs · provider pattern) are delivered by composing existing components + one small, provider-pattern-aligned enhancement — not a bespoke auth.idp/JWKS/refresh implementation.

Shipped

• workflow-plugin-sso v0.1.8 (chore(auth): require workflow v0.57.2 #18 + docs(auth): verified banner + CONTRIBUTING + examples + CHANGELOG (QoL sweep) #19): sso.oidc gains a jwksUri verify-only mode (oidc.NewRemoteKeySet+NewVerifier, signingAlgorithms incl. ES256) — verify a JWT from a published JWKS with no shared secret and no OIDC discovery. (Plus the proto-contract fix that an incomplete v0.1.7 exposed.)
• workflow-scenarios scenario 102 (#68): App A (engine auth.m2m ES256 issuer + /oauth/jwks) ↔ App B (sso.oidc jwksUri verifier) across two processes. Verified: curl smoke 12/12 (accept via App A's public JWKS; reject wrong-key/aud/issuer/expired/garbage — proves genuine asymmetric, not same-key) + Playwright 8/8 + playwright-cli QA (✓ verified / ✗ rejected console).
• workflow-plugin-auth (docs: auth use-case matrix + cross-service asymmetric auth design (closes #41) #43): README "Auth Use Cases & Combinations" matrix (which step/module combination covers each: same-app HS256 · admin bootstrap · M2M asymmetric ES256 · external-IDP human OIDC · enterprise SSO/SCIM · credential mgmt) + SPEC T-AUTH-16 + design + ADR-0003.

Coverage map

Need	Component
App-to-app asymmetric ES256 issue + JWKS	engine auth.m2m
Cross-service verification (no shared secret, no discovery)	sso.oidc jwksUri + step.sso_validate_token
Refresh / token exchange	step.sso_refresh_token / step.sso_token_exchange (OIDC) ; M2M = re-issue
External IDPs (Ory/Auth0/Entra/Okta)	provider pattern: AuthProviderDescriptor + provider plugins
Human/browser login	OIDC login → step.sso_validate_token

ADR-0003 records choosing the sso-jwksUri verify path over engine auth.m2m multi-key verify or a bespoke IDP. Closing — supported + demonstrated + documented.