entra-token-validation

Skill: Entra Token Validation

The runtime counterpart to openapi-spec-reviewer. That skill checks what a spec declares in components/securitySchemes; this one checks what the service actually enforces at request time.

Trigger

Invoke when a user asks to:

• Audit, review or check token validation, JWT validation, or authentication in a service-cp-* repo
• Confirm a service is conformant with the Entra access token standard
• Add token validation to a service that trusts an unverified claim
• Diagnose why tokens are being rejected (or accepted when they should not be)

Invocation command: /entra-token-validation

Scope: service-cp-* runtime services only. For a spec's declared security schemes, use openapi-spec-reviewer instead.

---

Prerequisites

Load and internalise both knowledge documents before auditing. They are bundled with this skill in its knowledge/ directory (resolve relative to this SKILL.md):

• knowledge/validation-standard.md — the decisions and traps behind each check
• knowledge/conformance-suite.md — the test cases a conformant repo must carry

Then locate the service's own auth code. Do not assume package names — find them:

grep -rn "azp\|JWKSource\|DefaultJWTProcessor\|NimbusJwtDecoder\|Authorization" src/main --include='*.java' -l

If the service has no token validation at all, say so plainly, report it as a single Critical finding, and go straight to the Remediation stage — do not emit five empty lenses.

---

Audit process

Work through five lenses. For each finding record the file and line, so the report is navigable and so the remediation stage has an anchor.

Read the code before judging it. Several checks in the standard are deliberate omissions with a recorded rationale — flagging those as gaps is a false positive, and the standard names them.

Lens 1 — Signature and algorithm

The verifier must pin exactly one algorithm in its own configuration, not read alg from the token header and not infer it from the key set (Entra's JWKS entries carry no alg).