julien
bfa35d3283
## Bug
After a real sign-in against the Entra tenant, the callback rejected the flow with:
```
{"context":"AuthCallback","event":"auth.flow_error","failure":{"kind":"amr-missing"}}
```
The user landed on the SPA with `?auth_error=amr-missing` instead of authenticated. Every dev sign-in is blocked.
## Root cause
PR #107's `amr-missing` guard misread ADR-0011's intent. `amr` is an **optional** claim in Entra ID tokens: it's populated for fresh interactive sign-ins where Conditional Access asked for an MFA method, and frequently absent for SSO / refresh flows or in tenants where no CA policy is configured on the app registration. Rejecting tokens on empty `amr` blocks every legitimate sign-in against such a tenant.
ADR-0011 actually specifies:
- **Conditional Access** (org-side) is the enforcement layer for "MFA happened".
- The **`@RequireMfa({ freshness: 600 })`** decorator (designed-in, no v1 consumer) is what guards sensitive routes.
- The BFF surfaces `amr` through the audit log and the future guard, not as a callback precondition.
## Fix
- **[`auth.errors.ts`](apps/portal-bff/src/auth/auth.errors.ts)**: drop the `amr-missing` variant from the `AuthCodeFlowError` discriminator. Three failure modes left: `state-mismatch`, `flow-expired`, `token-exchange-failed`. MSAL's ID-token validation (signature, issuer, audience, exp, nbf) is the real gate at this stage.
- **[`auth.service.ts`](apps/portal-bff/src/auth/auth.service.ts)**: `toAuthenticatedUser` keeps extracting `amr` and passing it through (as a possibly-empty string array) so the structured log line and the future `@RequireMfa` guard still see it. The strict `if (amr.length === 0) throw` is replaced by a comment explaining the new shape.
- **[`auth.service.spec.ts`](apps/portal-bff/src/auth/auth.service.spec.ts)**: the `'throws amr-missing'` test becomes `'returns the user even when the ID token has no amr claim'` — asserts the array passes through empty rather than blocking the flow.
## Verification
- `nx run-many -t lint test build --projects=portal-bff` — green. **52/52 specs**.
- Manual smoke: end-to-end sign-in against the live tenant now lands cleanly on the SPA; Pino's `auth.signed_in` log shows the resolved identity with `amr` (often `[]` until CA is configured on the org side).
---------
Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #108
29 lines
946 B
TypeScript
29 lines
946 B
TypeScript
/**
|
|
* Typed failure modes of the OIDC callback. The controller maps each
|
|
* to a query-param identifier on the SPA redirect so the front-end
|
|
* can render an appropriate message without inventing strings.
|
|
*
|
|
* Keep this list flat — the controller's `switch` is exhaustive
|
|
* thanks to TypeScript's narrowing on `kind`.
|
|
*/
|
|
export type AuthCodeFlowError =
|
|
| { kind: 'state-mismatch' }
|
|
| { kind: 'flow-expired' }
|
|
| { kind: 'token-exchange-failed'; cause: string };
|
|
|
|
export class AuthCodeFlowException extends Error {
|
|
constructor(readonly failure: AuthCodeFlowError) {
|
|
super(`auth code flow failed: ${failure.kind}`);
|
|
this.name = 'AuthCodeFlowException';
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Stable short codes used as `?auth_error=<code>` on the SPA-bound
|
|
* redirect. Same identifiers as the discriminant `kind` so log
|
|
* grepping correlates trivially.
|
|
*/
|
|
export function authErrorCode(failure: AuthCodeFlowError): string {
|
|
return failure.kind;
|
|
}
|