@crvouga/mockingbird-service-oauth 3.6.0 → 3.8.0

package/CHANGELOG.md

@@ -1,6 +1,18 @@
 # Changelog — @crvouga/mockingbird-service-oauth
 
-## 3.6.0 (2026-10-16)
+## 3.8.0 (2026-10-19)
+
+### Features
+
+- resolve the agent-reported issue queue in one batch ([25c52b6](https://github.com/crvouga/mockingbird/commit/25c52b668a53ddb80b968419601a20abf33f956b))
+
+## 3.7.0 (2026-10-16)
+
+### Features
+
+- resolve fleet and emulator issue batch ([26d2f8c](https://github.com/crvouga/mockingbird/commit/26d2f8cee99fefed93192204bac44fb1be35c1da))
+
+## 3.6.0 (2026-10-15)
 
 ### Features
 

package/README.md

@@ -172,7 +172,7 @@ tapping `oauth-mock-form-post-continue`; with scripts, the page submits the form
 
 ### Fidelity and lifecycle
 
-- Authorization-code flow with exact redirect matching, including explicitly registered private-use URI schemes for native apps, state and nonce; duplicate parameters rejected. Invalid clients/callbacks never redirect. Public native clients require S256 PKCE.
+- Authorization-code flow with exact redirect matching, including explicitly registered private-use URI schemes for native apps, state and nonce; duplicate parameters rejected. Invalid clients/callbacks never redirect. Public native clients require S256 PKCE unless the client opts in with `pkceOptional`.
 - Real RSA-2048 / RS256 ID tokens and independent public JWKS; correct issuer, audience, expiry, auth time and scope-filtered claims. Keys remain stable until explicitly rotated.
 - Codes expire after 5 minutes and are consumed atomically, including concurrent PKCE redemption. Access/ID tokens last 1 hour. Generic OIDC refresh tokens default to 30 days; Microsoft defaults to 90 days. Apple/Google refresh tokens have no fixed deadline by default; Google inactivity, testing mode and issuance limits still apply. GitHub OAuth app access tokens have no fixed deadline in the emulator. The injected emulator clock controls expiry.
 - Google `access_type=offline` issues refresh tokens on first consent or `prompt=consent`; generic/Microsoft `offline_access` and Apple issue refresh tokens. Refresh cannot expand scopes. Revocation invalidates related access and refresh tokens; unknown tokens succeed idempotently. Refresh tokens are reusable by default; Microsoft returns a replacement without invalidating the old token. Opt-in strict rotation detects reuse and revokes the token family.
@@ -306,13 +306,26 @@ no grants or account changes. Interactive vendor flows cannot be run unattended
 provider applications, so the focused contract tests use the official behavior documented in the
 references below.
 
+## Per-client opt-ins
+
+Defaults stay strict; these `Client` fields (also accepted by `POST /__admin/clients`) relax one rule each, for one client.
+
+| Field | Effect |
+| --- | --- |
+| `pkceOptional: true` | A public client (no `secret`, no `apple`) may omit PKCE, as a [Cognito public app client](https://docs.aws.amazon.com/cognito/latest/developerguide/authorization-endpoint.html) can. A challenge that is sent must still be S256 and is verified at the token endpoint. Conflicts with `requirePkce: true` and with `secret`/`apple`. |
+| `alwaysIssueRefreshToken: true` | Every authorization-code exchange returns a `refresh_token` without `offline_access`, as [Cognito's token endpoint](https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html) does. `oidc` and `microsoft` profiles only; Google, Apple and GitHub keep their own rules. |
+| `redirectPolicy: { loopbackAnyPort: true }` | RFC 8252 section 7.3: an `http://` loopback redirect (`127.0.0.1`, `[::1]`, `localhost`) may use any port. It must match a registered loopback URI on the same host, path and query. |
+| `redirectPolicy: { schemes: ["exp:"] }` | For the listed custom schemes the host and port may vary (a dev client's LAN address). The request must still match a registered URI with the same scheme, path and query. `http:`, `https:` and executable schemes are rejected. |
+
+A Cognito-shaped public client is `{ id, name, redirectUris, pkceOptional: true, alwaysIssueRefreshToken: true }` on an `oidc` mount (for example `/oauth2`). Extra authorize parameters such as `identity_provider` are ignored. The token exchange still requires the exact `redirect_uri` that authorized the code. These are matching rules for registered URIs, not wildcards: a URI that is not a variant of a registered one is still refused without a redirect.
+
 ## Deliberately not modelled
 
 This is a ready-to-use local/test identity provider, **not a production authentication server or a claim that every proprietary provider feature is implemented**. Its ready tier covers the documented OAuth/OIDC login, identity, consent, token, provider-edge-case, and UI surface. Applications should still run a small final check against each real provider before release.
 
 Vendor-hosted Google Identity Services/One Tap, native Apple AuthenticationServices, passkeys, MFA, CAPTCHA, password recovery, email delivery/relay forwarding (only Apple's notification of a forwarding change is sent), app-transfer migration, vendor risk engines, tokeninfo/introspection, logout, GitHub Apps installation/device flows, and Microsoft Graph/tenant administration are not implemented. Other configurable OIDC providers can use the generic profile, but their proprietary scopes and claims are not emulated. Scopes are limited to each profile plus explicitly configured additional scopes. Microsoft uses the configured emulator issuer, not real Entra tenant routing. GitHub is the OAuth app login surface, not the full REST API.
 
-No implicit flow, dynamic client registration, wildcard redirect matching, persistent signing-key storage (keys are held in memory; supply them through `signingKeys` or derive them from a seed), or distributed-session coordination is provided. Private-use redirect schemes work only when their complete URI is explicitly registered; executable/local schemes such as `javascript:`, `data:` and `file:` are rejected. Sign-in and consent pages extend CSP `form-action` with the transaction's redirect origin (or custom scheme). Browser navigation responses use a provider-owned handoff document so the callback can relay through another origin without inheriting the consent form's policy; direct programmatic interaction requests retain their HTTP redirect response. The `form_post` hand-off page sends no `form-action` at all: browsers apply that directive to every redirect after the submit, and the callback that receives the POST may redirect to an application origin the provider never sees, so no allow-list can cover it. The rest of that page's policy (`default-src 'none'`, nonce-only scripts and styles, `base-uri 'none'`, `frame-ancestors 'none'`) is unchanged. Discovery, JWKS, token, userinfo and revoke answer `OPTIONS` preflights and reflect the request `Origin`, so browser (SPA + PKCE) clients can redeem codes directly; the interaction pages send no CORS headers. Snapshot restore is for the same runtime/instance; signing keys are not serialized. The default backing store is in-memory and state disappears when the process exits. A secure browser context and Web Crypto, Fetch and standard Web APIs are required; Node 22+, Bun and modern browsers provide them.
+No implicit flow, dynamic client registration, wildcard redirect matching (beyond the opt-in `redirectPolicy`), persistent signing-key storage (keys are held in memory; supply them through `signingKeys` or derive them from a seed), or distributed-session coordination is provided. Private-use redirect schemes work only when their complete URI is explicitly registered; executable/local schemes such as `javascript:`, `data:` and `file:` are rejected. Sign-in and consent pages extend CSP `form-action` with the transaction's redirect origin (or custom scheme). Browser navigation responses use a provider-owned handoff document so the callback can relay through another origin without inheriting the consent form's policy; direct programmatic interaction requests retain their HTTP redirect response. The `form_post` hand-off page sends no `form-action` at all: browsers apply that directive to every redirect after the submit, and the callback that receives the POST may redirect to an application origin the provider never sees, so no allow-list can cover it. The rest of that page's policy (`default-src 'none'`, nonce-only scripts and styles, `base-uri 'none'`, `frame-ancestors 'none'`) is unchanged. Discovery, JWKS, token, userinfo and revoke answer `OPTIONS` preflights and reflect the request `Origin`, so browser (SPA + PKCE) clients can redeem codes directly; the interaction pages send no CORS headers. Snapshot restore is for the same runtime/instance; signing keys are not serialized. The default backing store is in-memory and state disappears when the process exits. A secure browser context and Web Crypto, Fetch and standard Web APIs are required; Node 22+, Bun and modern browsers provide them.
 
 References: [Google OpenID Connect](https://developers.google.com/identity/openid-connect/openid-connect), [Apple authorization request](https://developer.apple.com/documentation/signinwithapplerestapi/request-an-authorization-to-the-sign-in-with-apple-server.), and [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html).