@seamless-auth/oidc-provider 0.2.0 → 0.4.0

package/CHANGELOG.md

@@ -1,5 +1,52 @@
 # @seamless-auth/oidc-provider
 
+## 0.4.0
+
+### Minor Changes
+
+- 307f05d: Carry roles, permissions and custom claims in provider tokens (#47).
+  
+  - New scopes `permissions` (`roles`, `permissions`, `org_id`, `org_roles`, `org_permissions`, or `permissions_omitted`) and `custom_claims` (every custom claim the API resolves for the user and the application). They appear in ID tokens, `/userinfo`, and a user's RFC 9068 access token for a resource when the grant holds the scope. The consent page describes both.
+  - The values come from the API's `/oidc/accounts/:id` and the API signs only what it computes again, so the edge cannot add or change one. Reserved claim names are never released, and the permission claims are released whole or not at all.
+  - When the API refuses a sign with `claims_mismatch` (a role or membership changed between the account read and the sign), the edge reads the account again and signs once more, so the token request succeeds with the new values. A second mismatch answers `server_error` (500) with a description. Other refusals are not retried.
+  - `org_id` now names the session's active organization rather than the user's oldest membership. This changes `org_id` under the `seamless` scope too.
+  - Needs a seamless-auth-api release that returns these claims and signs them. Against an older API none are released.
+  - Depend on `@seamless-auth/types` `^0.40.0` for the shared reserved claim list, the account claims schema and the `claims_mismatch` refusal code.
+- 18b472c: The edge now follows the API's provider key rotation without a restart. It used to load the signing keys once at startup, so after the API rotated its active key every token request failed with `unknown_key` until the edge restarted, and `/jwks` and JWT access token introspection kept the startup keys. It now re-reads the keys every five minutes and at once when the API refuses a key as unknown (at most the request that meets the rotation fails), and `/jwks` serves the current set. Embedders can set the interval with the new `signingKeyRefreshMs` option (`0` turns the timer off). A rotation to a key with a different algorithm is refused with a logged error and still needs a restart. `SigningKeyRing` is exported for custom setups.
+- 18b472c: `TRUST_PROXY` now takes a hop count (`2` for a CDN in front of a load balancer) or a comma-separated list of proxy addresses and subnets (`10.0.0.0/8, 172.16.0.5`, or Express's `loopback`, `linklocal` and `uniquelocal`), and is passed to Express's `trust proxy` as is. Behind more than one proxy the edge used to forward the last proxy's address as the client IP, so users shared the API's per-IP rate limits and lockouts. `true` still means one hop and `false` none, so existing deployments are unchanged; a value that is neither a hop count nor valid addresses now stops the service at startup. Keep the container port reachable only through the proxy.
+
+### Patch Changes
+
+- bfff063: Depend on `@seamless-auth/core` and `@seamless-auth/express` `^0.26.0`. On 0.x, `^0.23.0` stopped at 0.23, so the edge ran on 0.23 and an application installing the provider got a second, older copy of both. The edge now has the adapter fixes from 0.25: the CSRF origin check on form posts to the auth routes (seamless-auth-server#256), no replay of a completed bearer refresh rotation (#258), no client-chosen client IP under a `trust proxy` that trusts every address (#257), and a bundled adapter manifest with the v0.23 routes.
+  
+  The hosted pages build against `@seamless-auth/react` 0.20 and `@seamless-auth/client` 0.9. Client 0.8.2 sent body-less requests such as the passkey step-up start without a JSON content type or the transport header, and adapters from 0.25 refuse those with 415, so step-up needs the newer client.
+- 216b785: The confirmation for a native client now names the account as well as the client. `GET /interaction/:uid/details` returns `account: { identifier }` (the account's email, or its phone number if it has none), or `account: null` unless the browser is signed in as the interaction's account and the API can describe it. The hosted "Continue to <app>?" card shows the identifier, and with no account to name it offers only Cancel. If you serve your own pages through `uiDir`, show `account.identifier` beside the client name, send `{ "confirmed": true }` only from a real click, and do not offer to continue when `account` is `null`.
+- 7858f18: A device client polling an expired device code faster than its interval now gets `expired_token`, so it stops, rather than `slow_down` on every poll. The poll throttle only tracks codes that have not expired. With an API that keeps expired device codes readable for a while (seamless-auth-api#542), the token endpoint answers `expired_token` for them; a code the API does not know still gets `invalid_grant`.
+- 7858f18: Errors the provider cannot send back to the app now render on the hosted pages, with your branding, instead of the library's default "oops! something went wrong" page. That covers an unknown `client_id`, an unregistered `redirect_uri` at `/authorize`, and a refused `/session/end` (an unregistered `post_logout_redirect_uri`, or an `id_token_hint` that cannot be read). The page shows the error code, the provider's description and a plain explanation, and answers with the hosted pages' CSP and `no-store`. A server error shows a generic description.
+- 7858f18: The hosted pages meet WCAG 2.2 AA with the default palette and a sound custom one (see `docs/accessibility-audit.md`).
+  
+  - The sign-in screens' mode toggle, error text and hovered button now take this service's palette, and follow `hosted_ui` branding, instead of fallback colors that fell below 4.5:1.
+  - Text field edges are darker (`#7a828e` light, `#8a93a0` dark) so they meet 3:1, which also darkens card borders.
+  - Sign-out, device and error pages are titled for what they do rather than "Sign in to <app>".
+  - The device code error is tied to the code field.
+  - When the hosted pages render with a `hosted_ui` palette whose pairs fall below AA contrast, the service logs one warning naming each pair. Nothing is refused.
+- 18b472c: A failure while finishing a login no longer leaves a grant behind, and unexpected errors are answered as JSON. `POST /interaction/:uid/login` saves the grant before it reads the auth context; when that read failed (the API unreachable, say), the grant stayed and bound the first-party session to the client without a finished sign-in. The edge router also had no error handler, so such failures reached Express's default handler, which answers HTML with a stack trace whenever `NODE_ENV` is not `production`. They now answer `500 {"error":"server_error"}` (logged by name and message), and a malformed request body answers its 4xx status with `{"error":"invalid_request"}`.
+- 18b472c: `/session/end` no longer signs a browser out of the hosted pages when it has no provider sign-in. The library ends an empty provider session without a confirmation page, and the edge used to clear the first-party adapter cookies on that automatic post, so any site that sent a browser to `/session/end` signed it out. The first-party session and its cookies are now ended only when the provider session had an account and the user confirmed on the hosted page.
+- 18b472c: A first-party native client (`application_type: native`) no longer gets a code without a click. Any program on the device can listen on a loopback port or claim a private-use scheme, so a signed-in user's browser could otherwise hand a code to it with no interaction (RFC 8252 section 8.6). The hosted pages now show a "Continue to <app>" confirmation for every native client request, after sign-in and on later requests that ride the provider session, and `POST /interaction/:uid/consent` answers `403 confirmation_required` for a native client's prompt unless the body is `{ "confirmed": true }`. A custom hosted UI must send that body from the user's click. Web clients and device-flow approvals are unchanged.
+- 7858f18: A request object that asks for `response_mode=form_post` now gets its `request_not_supported` refusal by form post rather than in the query string. Request objects are still not supported. Only `response_mode` is read from the refused object, without verifying it, and only the value `form_post` changes anything: the error still goes only to the request's own `redirect_uri` once it is checked against the client's registered URIs, and no other value from the object is used or shown. This lets the Form Post OP conformance profile pass `oidcc-unsigned-request-object-supported-correctly-or-rejected-as-unsupported`.
+- 18b472c: The device poll throttle and the resume cookie check now match paths the way the provider's router does. A device client polling `/token/` was never told `slow_down`, because the throttle only recognised the exact path `/token`; it now follows the provider's own routing, so every spelling the provider accepts is throttled. The check that a resumed authorization is the one the resume cookie names now also covers `/authorize/<uid>/` and a differently cased `/AUTHORIZE/<uid>`.
+- abb4834: Depend on `@seamless-auth/types` `^0.36.0`, which adds the session exchange contract.
+
+## 0.3.0
+
+### Minor Changes
+
+- 047779c: A user's JWT access token for a resource (RFC 9068) now carries the session's `acr`, `amr` and `auth_time`, the same values the ID token states, and introspection returns them. A resource server can require a recent phishing-resistant sign-in on a route from the token alone (RFC 9470), and a refreshed token carries the session's current values, so a step-up shows on the next refresh. Device-flow and client credentials tokens carry none of the three, and opaque `/userinfo` tokens are unchanged. Needs no API change: Seamless Auth API 0.22.0 signs these claims and checks them against the session.
+
+### Patch Changes
+
+- 7c86020: Device-flow ID tokens no longer carry the approving session's `amr` and `auth_time`, first or after a refresh. Seamless Auth API 0.22.0 refuses to sign any device-flow token that states `acr`, `amr` or `auth_time` (ADR 0001 D10), so a device-flow request asking for `openid` ended in `server_error` against it.
+
 ## 0.2.0
 
 ### Minor Changes

package/README.md

@@ -16,6 +16,10 @@ any OIDC app ──► seamless-auth-oidc-provider (public: OIDC endpoints, host
 - Built on [`oidc-provider`](https://github.com/panva/node-oidc-provider) 9.x.
 - Holds no private keys and no database. The API signs every token after checking its claims,
   and stores all provider state.
+- Follows the API's key rotation without a restart. It re-reads the API's keys every five
+  minutes (`signingKeyRefreshMs` when embedded), and at once when the API refuses a key as
+  unknown, so at most the request that meets a rotation fails. `/jwks` serves the current set.
+  Rotating to a key with another algorithm still needs a restart.
 - Code flow with PKCE (a confidential client can be opted out, and then sends `nonce` unless that is waived too), refresh rotation always on, `private_key_jwt` for confidential
   clients, and shared secrets only for clients opted in on the API.
 
@@ -35,6 +39,13 @@ The design is in
   hosted pages.
 - HTTPS. Provider cookies are `__Host-` cookies, which browsers only accept over TLS.
 
+## Run it on your laptop
+
+[`local/README.md`](local/README.md) goes from nothing to a passkey sign-in on the hosted page and a
+JWT access token for your own API on one page: a compose file with the API, Postgres and this
+service behind local TLS, generated keys, and a seed for the clients and the resource. The
+production checks stay on.
+
 ## Run the image
 
 ```bash
@@ -43,16 +54,28 @@ docker run -p 5314:5314 --env-file .env ghcr.io/fells-code/seamless-auth-oidc-pr
 
 ## Configuration
 
-| Variable                      | Required | Description                                                                                                                                                                                            |
-| ----------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `SEAMLESS_API_URL`            | yes      | The private API, as this service reaches it.                                                                                                                                                           |
-| `SEAMLESS_API_ISSUER`         | no       | The API's `ISSUER`, when it differs from `SEAMLESS_API_URL`.                                                                                                                                           |
-| `SEAMLESS_OIDC_SERVICE_TOKEN` | yes      | This service's own service token secret, `SEAMLESS_OIDC_SERVICE_TOKEN` on the API. It must differ from the adapters' `SEAMLESS_SERVICE_TOKEN`, which this service never holds. At least 32 characters. |
-| `SEAMLESS_JWKS_KID`           | no       | The `kid` on the service tokens this service signs.                                                                                                                                                    |
-| `SEAMLESS_COOKIE_SECRET`      | yes      | Signs the first-party session cookies. At least 32 characters.                                                                                                                                         |
-| `OIDC_COOKIE_KEYS`            | yes      | Comma-separated provider cookie keys. The first signs, the rest verify.                                                                                                                                |
-| `TRUST_PROXY`                 | no       | `true` when TLS ends at a proxy in front of this service.                                                                                                                                              |
-| `PORT`                        | no       | Defaults to `5314`.                                                                                                                                                                                    |
+| Variable                      | Required | Description                                                                                                                                                                                                                                                                                              |
+| ----------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `SEAMLESS_API_URL`            | yes      | The private API, as this service reaches it.                                                                                                                                                                                                                                                             |
+| `SEAMLESS_API_ISSUER`         | no       | The API's `ISSUER`, when it differs from `SEAMLESS_API_URL`.                                                                                                                                                                                                                                             |
+| `SEAMLESS_OIDC_SERVICE_TOKEN` | yes      | This service's own service token secret, `SEAMLESS_OIDC_SERVICE_TOKEN` on the API. It must differ from the adapters' `SEAMLESS_SERVICE_TOKEN`, which this service never holds. At least 32 characters.                                                                                                   |
+| `SEAMLESS_JWKS_KID`           | no       | The `kid` on the service tokens this service signs.                                                                                                                                                                                                                                                      |
+| `SEAMLESS_COOKIE_SECRET`      | yes      | Signs the first-party session cookies. At least 32 characters.                                                                                                                                                                                                                                           |
+| `OIDC_COOKIE_KEYS`            | yes      | Comma-separated provider cookie keys. The first signs, the rest verify.                                                                                                                                                                                                                                  |
+| `TRUST_PROXY`                 | no       | The proxies in front of this service, as Express's `trust proxy`: the number of hops (`2` for a CDN in front of a load balancer), or a comma-separated list of proxy addresses and subnets (`10.0.0.0/8, 172.16.0.5`). `true` means one hop. Defaults to `false`. See [Behind a proxy](#behind-a-proxy). |
+| `PORT`                        | no       | Defaults to `5314`.                                                                                                                                                                                                                                                                                      |
+
+### Behind a proxy
+
+The client IP this service forwards to the API decides who shares its per-IP rate limits and
+lockouts, and Express reads it from `X-Forwarded-For` through `TRUST_PROXY`. Set it to the
+proxies actually in front of this service: with too few hops every user arrives as the CDN
+node, and with too many the client picks its own address. A list of addresses and subnets
+holds even when the number of hops varies.
+
+Make the container port reachable only through the proxy. A client that can reach it directly
+writes the last `X-Forwarded-For` entry and `X-Forwarded-Proto` and `X-Forwarded-Host`
+itself, and that address goes to the API under this service's token.
 
 The issuer comes from the API (`oidc_issuer`), not from this service's environment. The service
 answers only requests for the issuer's own scheme and host, and refuses to start when the API
@@ -105,6 +128,14 @@ and `jti`, with only the scopes the application is allowed there and the resourc
 lifetime. The API checks the same links again before it signs, so an API configured for one
 identifier can reject every token minted for another.
 
+A user's token for a resource also carries the session's `acr`, `amr` and `auth_time` (RFC
+9068 section 2.2.1), the values the ID token states, and introspection returns them. An API can
+then require a recent phishing-resistant sign-in on a route from the token alone, and answer
+`insufficient_user_authentication` (RFC 9470) when it falls short. A refreshed token carries the
+session's current values, so a step-up shows on the next refresh. The API signs only the values
+the session holds, so the edge cannot raise them. Device-flow and client credentials tokens
+carry none of the three, and an opaque `/userinfo` token gains nothing.
+
 - A resource the application is not linked to is refused with `invalid_target`.
 - An app that named one resource at authorization gets its token without repeating
   `resource` at the token endpoint.
@@ -113,6 +144,35 @@ identifier can reject every token minted for another.
 - First-party apps have the scopes granted with the sign-in. Third-party apps list them on the
   consent page.
 
+## Roles, permissions and custom claims
+
+Two scopes release the authorization claims a first-party Seamless token carries (API ADR 0004
+and ADR 0005), under the same names:
+
+| Scope           | Claims                                                                                      |
+| --------------- | ------------------------------------------------------------------------------------------- |
+| `permissions`   | `roles`, `permissions`, `org_id`, `org_roles`, `org_permissions` (or `permissions_omitted`) |
+| `custom_claims` | every custom claim the API resolves for the user and this application                       |
+
+They appear in the ID token and `/userinfo`, and in a user's access token for a resource when the
+grant holds the scope (the access token's own `scope` lists only the resource's scopes). The older
+`seamless` scope still releases `roles` and `org_id` alone.
+
+- `org_id` and the `org_*` claims name the session's active organization, while the user is still
+  a member of it.
+- Custom claims come from the user's instance roles, then their roles in the active organization,
+  then the application's own set (`/admin/custom-claims/oidc_client/:clientId`), then the
+  `pre_token` login hook, a later source winning per name. Reserved names are never released.
+- Permission and custom claims share one 1 KiB budget. Over it, the permission claims become
+  `"permissions_omitted": true` first (read `GET /users/me/permissions` then), and custom claims
+  are dropped whole only when they do not fit beside that marker. Nothing is trimmed in part.
+- The API computes every value and signs only what matches its own computation for the session
+  and application, so this service cannot add, raise or forge one. A role change shows on the
+  next token or refresh. If it lands between this service's read and the API's sign, the API
+  refuses with `claims_mismatch` and this service reads the account again and signs once more; a
+  second mismatch answers `server_error`.
+- Client credentials tokens carry none of them.
+
 ## Token lifetimes
 
 An application's own `accessTokenTtlSeconds`, `idTokenTtlSeconds` and `refreshTokenTtlSeconds`
@@ -130,9 +190,9 @@ ends every record when the first-party session behind it ends.
   tokens rotate on every use. A used one presented again revokes the grant and every token
   under it, and the API ends the first-party session it was issued under. Two refreshes
   racing with the same token cannot both rotate: the API's consume says which one marked it
-  used, and the other is handled as that same reuse. A refreshed ID
-  token carries the session's current `acr`, `amr` and `auth_time`, so a step-up since the
-  sign-in shows up on the next refresh.
+  used, and the other is handled as that same reuse. A refreshed ID token, and a refreshed
+  access token for a resource, carry the session's current `acr`, `amr` and `auth_time`, so a
+  step-up since the sign-in shows up on the next refresh.
 - **Client credentials.** A confidential client registered for `client_credentials` gets an
   RFC 9068 JWT whose `sub` and `client_id` are the client itself, only ever for a resource:
   the one named with `resource`, or the client's only linked resource. Scopes are cut to what
@@ -171,6 +231,11 @@ ends:
   adapter cookies. Every other app the user signed in to with it is signed out too.
 - **Only sign out of** the asking app ends that app's grant and keeps the session.
 
+When the browser has no provider sign-in there is nothing to confirm, and the library ends its
+empty provider session without a page. The first-party session and the adapter cookies are
+left alone then, so a site that sends a browser to `/session/end` cannot sign it out of the
+hosted pages.
+
 Back-channel logout (OpenID Back-Channel Logout 1.0) is sent by the API, not by this service.
 The API holds the keys and sees every way a session ends (this logout, admin revoke, sign-out
 everywhere, eviction), so a client with a `backchannelLogoutUri` gets a `logout+jwt` token
@@ -192,9 +257,10 @@ off unless an admin enables the device flow on a first-party application (ADR D1
   section 5.4). Every approval signs in again, so a browser that is already signed in still
   confirms with the passkey. Code entry is limited to 10 a minute per address and 600 a
   minute per instance.
-- **Assurance.** Device-flow tokens never carry `acr`, after a refresh too, and device requests
-  with `acr_values` or `max_age` are refused. The passkey proves who approved, not who holds
-  the device. The API refuses `acr` on any token whose sign request names the device grant.
+- **Assurance.** Device-flow tokens never carry `acr`, `amr` or `auth_time`, after a refresh
+  too, and device requests with `acr_values` or `max_age` are refused. The passkey proves who
+  approved, not who holds the device. The API refuses all three on any token whose sign request
+  names the device grant.
 
 ## Security defaults
 
@@ -228,6 +294,19 @@ same way any Seamless app does, then finish the OIDC interaction.
   screens. A recovery session goes to enrollment before it can finish a sign-in.
 - **Consent.** First-party clients have consent implied. Third-party clients see the client
   name, the host they are sent back to and the requested scopes, on every authorization.
+- **Native apps.** Any program on a device can listen on a loopback port or claim a private-use
+  scheme, so every request from a native client (`application_type: native`), first-party
+  included, waits for the user to click "Continue to <app>" (RFC 8252 section 8.6). The card names
+  the client and the account, as `account.identifier` (an email or phone number) from
+  `GET /interaction/:uid/details`, and that field is `null` unless this browser is signed in as the
+  interaction's account and the API can describe it. With no account to name, the page offers only
+  Cancel. The consent route refuses a native prompt with `403 confirmation_required` unless the
+  page sends `{ "confirmed": true }` from that click. Device-flow approvals are confirmed on the
+  device pages instead, before sign-in, so those name the client and the user code only.
+- **Custom pages.** `hosted_ui` only brands these pages. If you replace them with your own (the
+  `uiDir` option), your confirmation must do the same: show `account.identifier` beside the client
+  name as text, send `{ "confirmed": true }` only from a real click, and not offer to continue when
+  `account` is `null`. The edge cannot check any of this for you.
 - **Branding.** The app name comes from the API's config each time a page is served, so a
   config change needs no build and no restart.
 - **Headers.** A strict CSP (`script-src 'self'`, styles from this origin or with the

package/dist/accessTokenClaims.d.ts

@@ -0,0 +1,29 @@
+import type { KoaContextWithOIDC } from 'oidc-provider';
+interface IssuedToken {
+    kind?: unknown;
+    gty?: unknown;
+    scope?: unknown;
+    resourceServer?: unknown;
+}
+/**
+ * ADR 0002 N7: a user's access token for a resource carries `acr`, `amr` and `auth_time`
+ * (RFC 9068 section 2.2.1), so a resource server can require step-up from the token alone.
+ * They come from the code or refresh token the grant redeems, the same values the ID token
+ * states, which the adapter took from the API's auth context. Introspection returns them too,
+ * because the library stores these claims with the token.
+ *
+ * A device-flow token states none (ADR 0001 D10), a client credentials token has no user, and
+ * an opaque token for userinfo gains nothing.
+ */
+export declare function accessTokenAuthContext(ctx: KoaContextWithOIDC | undefined, token: IssuedToken): Record<string, unknown> | undefined;
+/**
+ * seamless-auth-oidc-provider#47: a user's access token for a resource carries the roles,
+ * permissions and custom claims a first-party token does, when the client was granted
+ * `permissions` or `custom_claims`. The token's own `scope` lists only the resource's scopes, so
+ * the grant is read from the code or refresh token it redeems. The values are the ones the
+ * library loaded for this request, which `/oidc/sign` computes again before it signs. A device
+ * flow token carries them too: they describe the user, not how the sign-in was made.
+ */
+export declare function accessTokenAuthorization(ctx: KoaContextWithOIDC | undefined, token: IssuedToken): Record<string, unknown> | undefined;
+export declare function accessTokenClaims(ctx: KoaContextWithOIDC | undefined, token: IssuedToken): Record<string, unknown> | undefined;
+export {};

package/dist/accessTokenClaims.js

@@ -0,0 +1,67 @@
+/*
+ * Copyright © 2026 Fells Code, LLC
+ * Licensed under the Apache License, Version 2.0
+ * See LICENSE file in the project root for full license information
+ */
+import { SESSION_EXCHANGE_SCOPE } from '@seamless-auth/types';
+import { authorizationClaimsFor, providerAccountOf } from './accountClaims.js';
+import { isDeviceGrant } from './deviceFlow.js';
+import { currentRequestContext } from './requestContext.js';
+/**
+ * ADR 0002 N7: a user's access token for a resource carries `acr`, `amr` and `auth_time`
+ * (RFC 9068 section 2.2.1), so a resource server can require step-up from the token alone.
+ * They come from the code or refresh token the grant redeems, the same values the ID token
+ * states, which the adapter took from the API's auth context. Introspection returns them too,
+ * because the library stores these claims with the token.
+ *
+ * A device-flow token states none (ADR 0001 D10), a client credentials token has no user, and
+ * an opaque token for userinfo gains nothing.
+ */
+export function accessTokenAuthContext(ctx, token) {
+    if (!ctx?.oidc ||
+        token.kind !== 'AccessToken' ||
+        !token.resourceServer ||
+        isDeviceGrant(token) ||
+        currentRequestContext()?.deviceFlow) {
+        return undefined;
+    }
+    const entities = ctx.oidc.entities;
+    const source = entities.RefreshToken ?? entities.AuthorizationCode;
+    if (!source) {
+        return undefined;
+    }
+    return {
+        ...(source.acr ? { acr: source.acr } : {}),
+        ...(source.amr && source.amr.length > 0 ? { amr: [...source.amr] } : {}),
+        ...(typeof source.authTime === 'number' ? { auth_time: source.authTime } : {}),
+    };
+}
+/**
+ * seamless-auth-oidc-provider#47: a user's access token for a resource carries the roles,
+ * permissions and custom claims a first-party token does, when the client was granted
+ * `permissions` or `custom_claims`. The token's own `scope` lists only the resource's scopes, so
+ * the grant is read from the code or refresh token it redeems. The values are the ones the
+ * library loaded for this request, which `/oidc/sign` computes again before it signs. A device
+ * flow token carries them too: they describe the user, not how the sign-in was made.
+ */
+export function accessTokenAuthorization(ctx, token) {
+    if (!ctx?.oidc || token.kind !== 'AccessToken' || !token.resourceServer) {
+        return undefined;
+    }
+    if (typeof token.scope === 'string' && token.scope.split(' ').includes(SESSION_EXCHANGE_SCOPE)) {
+        return undefined;
+    }
+    const account = providerAccountOf(ctx.oidc.account);
+    const entities = ctx.oidc.entities;
+    const grant = entities.RefreshToken ?? entities.AuthorizationCode ?? entities.DeviceCode;
+    if (!account || !grant) {
+        return undefined;
+    }
+    return authorizationClaimsFor(account, grant.scope);
+}
+export function accessTokenClaims(ctx, token) {
+    const authorization = accessTokenAuthorization(ctx, token);
+    const context = accessTokenAuthContext(ctx, token);
+    return authorization || context ? { ...authorization, ...context } : undefined;
+}
+//# sourceMappingURL=accessTokenClaims.js.map

package/dist/accessTokenClaims.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"accessTokenClaims.js","sourceRoot":"","sources":["../src/accessTokenClaims.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,OAAO,EAAE,sBAAsB,EAAE,MAAM,sBAAsB,CAAC;AAG9D,OAAO,EAAE,sBAAsB,EAAE,iBAAiB,EAAE,MAAM,oBAAoB,CAAC;AAC/E,OAAO,EAAE,aAAa,EAAE,MAAM,iBAAiB,CAAC;AAChD,OAAO,EAAE,qBAAqB,EAAE,MAAM,qBAAqB,CAAC;AAgB5D;;;;;;;;;GASG;AACH,MAAM,UAAU,sBAAsB,CACpC,GAAmC,EACnC,KAAkB;IAElB,IACE,CAAC,GAAG,EAAE,IAAI;QACV,KAAK,CAAC,IAAI,KAAK,aAAa;QAC5B,CAAC,KAAK,CAAC,cAAc;QACrB,aAAa,CAAC,KAAK,CAAC;QACpB,qBAAqB,EAAE,EAAE,UAAU,EACnC,CAAC;QACD,OAAO,SAAS,CAAC;IACnB,CAAC;IACD,MAAM,QAAQ,GAAG,GAAG,CAAC,IAAI,CAAC,QAGzB,CAAC;IACF,MAAM,MAAM,GAAG,QAAQ,CAAC,YAAY,IAAI,QAAQ,CAAC,iBAAiB,CAAC;IACnE,IAAI,CAAC,MAAM,EAAE,CAAC;QACZ,OAAO,SAAS,CAAC;IACnB,CAAC;IACD,OAAO;QACL,GAAG,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,GAAG,EAAE,MAAM,CAAC,GAAG,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QAC1C,GAAG,CAAC,MAAM,CAAC,GAAG,IAAI,MAAM,CAAC,GAAG,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,EAAE,GAAG,EAAE,CAAC,GAAG,MAAM,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QACxE,GAAG,CAAC,OAAO,MAAM,CAAC,QAAQ,KAAK,QAAQ,CAAC,CAAC,CAAC,EAAE,SAAS,EAAE,MAAM,CAAC,QAAQ,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;KAC/E,CAAC;AACJ,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,wBAAwB,CACtC,GAAmC,EACnC,KAAkB;IAElB,IAAI,CAAC,GAAG,EAAE,IAAI,IAAI,KAAK,CAAC,IAAI,KAAK,aAAa,IAAI,CAAC,KAAK,CAAC,cAAc,EAAE,CAAC;QACxE,OAAO,SAAS,CAAC;IACnB,CAAC;IACD,IAAI,OAAO,KAAK,CAAC,KAAK,KAAK,QAAQ,IAAI,KAAK,CAAC,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,QAAQ,CAAC,sBAAsB,CAAC,EAAE,CAAC;QAC/F,OAAO,SAAS,CAAC;IACnB,CAAC;IACD,MAAM,OAAO,GAAG,iBAAiB,CAAC,GAAG,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;IACpD,MAAM,QAAQ,GAAG,GAAG,CAAC,IAAI,CAAC,QAIzB,CAAC;IACF,MAAM,KAAK,GAAG,QAAQ,CAAC,YAAY,IAAI,QAAQ,CAAC,iBAAiB,IAAI,QAAQ,CAAC,UAAU,CAAC;IACzF,IAAI,CAAC,OAAO,IAAI,CAAC,KAAK,EAAE,CAAC;QACvB,OAAO,SAAS,CAAC;IACnB,CAAC;IACD,OAAO,sBAAsB,CAAC,OAAO,EAAE,KAAK,CAAC,KAAK,CAAC,CAAC;AACtD,CAAC;AAED,MAAM,UAAU,iBAAiB,CAC/B,GAAmC,EACnC,KAAkB;IAElB,MAAM,aAAa,GAAG,wBAAwB,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;IAC3D,MAAM,OAAO,GAAG,sBAAsB,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;IACnD,OAAO,aAAa,IAAI,OAAO,CAAC,CAAC,CAAC,EAAE,GAAG,aAAa,EAAE,GAAG,OAAO,EAAE,CAAC,CAAC,CAAC,SAAS,CAAC;AACjF,CAAC"}

package/dist/accountClaims.d.ts

@@ -0,0 +1,51 @@
+import { type OidcAccountClaims } from '@seamless-auth/types';
+import type { Account, Provider } from 'oidc-provider';
+/**
+ * What `/oidc/accounts/:id` returns since seamless-auth-oidc-provider#47: the ADR 0004
+ * permission claims under their token names, and the merged custom claims, all computed by the
+ * API for this session and client and already held to the shared budget.
+ */
+export declare const OidcProviderAccountSchema: import("zod").ZodObject<{
+    sub: import("zod").ZodString;
+    email: import("zod").ZodOptional<import("zod").ZodString>;
+    email_verified: import("zod").ZodOptional<import("zod").ZodBoolean>;
+    phone_number: import("zod").ZodOptional<import("zod").ZodString>;
+    phone_number_verified: import("zod").ZodOptional<import("zod").ZodBoolean>;
+    roles: import("zod").ZodArray<import("zod").ZodString>;
+    org_id: import("zod").ZodNullable<import("zod").ZodString>;
+    permissions: import("zod").ZodOptional<import("zod").ZodArray<import("zod").ZodString>>;
+    permissions_omitted: import("zod").ZodOptional<import("zod").ZodLiteral<true>>;
+    org_roles: import("zod").ZodOptional<import("zod").ZodArray<import("zod").ZodString>>;
+    org_permissions: import("zod").ZodOptional<import("zod").ZodArray<import("zod").ZodString>>;
+    customClaims: import("zod").ZodDefault<import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>, import("zod").ZodArray<import("zod").ZodUnion<readonly [import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>, import("zod").ZodArray<import("zod").ZodUnion<readonly [import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>, import("zod").ZodArray<import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>, import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>]>>, import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>, import("zod").ZodArray<import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>, import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>]>>]>>, import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>, import("zod").ZodArray<import("zod").ZodUnion<readonly [import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>, import("zod").ZodArray<import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>, import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>]>>, import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>, import("zod").ZodArray<import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>, import("zod").ZodRecord<import("zod").ZodString, import("zod").ZodUnion<readonly [import("zod").ZodString, import("zod").ZodNumber, import("zod").ZodBoolean, import("zod").ZodNull]>>]>>]>>]>>>;
+}, import("zod/v4/core").$strip>;
+export type OidcProviderAccount = OidcAccountClaims;
+/** Roles, permissions and the active organization's roles, as a first-party token has them. */
+export declare const PERMISSIONS_SCOPE = "permissions";
+/** Every custom claim the API resolved for the user and this client. */
+export declare const CUSTOM_CLAIMS_SCOPE = "custom_claims";
+/** `/oidc/sign` signs these together or not at all, since a partial list looks complete. */
+export declare const PERMISSION_CLAIMS: readonly ["permissions", "permissions_omitted", "org_roles", "org_permissions"];
+export declare const PERMISSIONS_SCOPE_CLAIMS: string[];
+declare const CUSTOM_CLAIMS: unique symbol;
+/** Reserved names are dropped here too, whatever the API sent, so none can replace a claim. */
+export declare function customClaimsOf(account: OidcProviderAccount): Record<string, unknown>;
+/** The claims the library filters by scope, with the custom claims kept aside for after it. */
+export declare function accountClaimsOf(account: OidcProviderAccount): {
+    sub: string;
+    [CUSTOM_CLAIMS]: Record<string, unknown>;
+};
+export declare function withAccount(account: Account, claims: OidcProviderAccount): Account;
+export declare function providerAccountOf(account: unknown): OidcProviderAccount | undefined;
+/** The authorization claims a scope set releases, by the names `/oidc/sign` expects. */
+export declare function authorizationClaimsFor(account: OidcProviderAccount, scope: unknown): Record<string, unknown>;
+/**
+ * The library releases only claims named in its static `claims` map, and custom claim names are
+ * the adopter's. ID tokens and userinfo both build their payload through `provider.Claims`, so
+ * this adds the account's custom claims there when `custom_claims` was granted, under every
+ * claim the library already chose. It also keeps the permission claims whole: a `claims`
+ * request or a rejection that asks for part of them gets none, rather than a token the API
+ * refuses to sign.
+ */
+export declare function releaseAuthorizationClaims(provider: Provider): void;
+export {};

package/dist/accountClaims.js

@@ -0,0 +1,102 @@
+/*
+ * Copyright © 2026 Fells Code, LLC
+ * Licensed under the Apache License, Version 2.0
+ * See LICENSE file in the project root for full license information
+ */
+import { isReservedClaimName, OidcAccountClaimsSchema, } from '@seamless-auth/types';
+/**
+ * What `/oidc/accounts/:id` returns since seamless-auth-oidc-provider#47: the ADR 0004
+ * permission claims under their token names, and the merged custom claims, all computed by the
+ * API for this session and client and already held to the shared budget.
+ */
+export const OidcProviderAccountSchema = OidcAccountClaimsSchema;
+/** Roles, permissions and the active organization's roles, as a first-party token has them. */
+export const PERMISSIONS_SCOPE = 'permissions';
+/** Every custom claim the API resolved for the user and this client. */
+export const CUSTOM_CLAIMS_SCOPE = 'custom_claims';
+/** `/oidc/sign` signs these together or not at all, since a partial list looks complete. */
+export const PERMISSION_CLAIMS = [
+    'permissions',
+    'permissions_omitted',
+    'org_roles',
+    'org_permissions',
+];
+export const PERMISSIONS_SCOPE_CLAIMS = ['roles', 'org_id', ...PERMISSION_CLAIMS];
+// A symbol, so the library's own copies of the claims carry it while no claim filter can
+// release it under a name.
+const CUSTOM_CLAIMS = Symbol('seamless.customClaims');
+const ACCOUNT_PROPERTY = 'seamlessAccount';
+/** Reserved names are dropped here too, whatever the API sent, so none can replace a claim. */
+export function customClaimsOf(account) {
+    return Object.fromEntries(Object.entries(account.customClaims).filter(([name]) => !isReservedClaimName(name)));
+}
+function standardClaimsOf(account) {
+    const { org_id, ...rest } = account;
+    delete rest.customClaims;
+    return { ...rest, ...(org_id ? { org_id } : {}) };
+}
+/** The claims the library filters by scope, with the custom claims kept aside for after it. */
+export function accountClaimsOf(account) {
+    return {
+        ...standardClaimsOf(account),
+        sub: account.sub,
+        [CUSTOM_CLAIMS]: customClaimsOf(account),
+    };
+}
+export function withAccount(account, claims) {
+    return Object.assign(account, { [ACCOUNT_PROPERTY]: claims });
+}
+export function providerAccountOf(account) {
+    const value = account?.[ACCOUNT_PROPERTY];
+    return value ? value : undefined;
+}
+function scopesOf(scope) {
+    return new Set(typeof scope === 'string' ? scope.split(' ') : []);
+}
+/** The authorization claims a scope set releases, by the names `/oidc/sign` expects. */
+export function authorizationClaimsFor(account, scope) {
+    const scopes = scopesOf(scope);
+    const standard = standardClaimsOf(account);
+    return {
+        ...(scopes.has(CUSTOM_CLAIMS_SCOPE) ? customClaimsOf(account) : {}),
+        ...(scopes.has(PERMISSIONS_SCOPE)
+            ? Object.fromEntries(PERMISSIONS_SCOPE_CLAIMS.filter((name) => name in standard).map((name) => [
+                name,
+                standard[name],
+            ]))
+            : {}),
+    };
+}
+const maskScopes = new WeakMap();
+/**
+ * The library releases only claims named in its static `claims` map, and custom claim names are
+ * the adopter's. ID tokens and userinfo both build their payload through `provider.Claims`, so
+ * this adds the account's custom claims there when `custom_claims` was granted, under every
+ * claim the library already chose. It also keeps the permission claims whole: a `claims`
+ * request or a rejection that asks for part of them gets none, rather than a token the API
+ * refuses to sign.
+ */
+export function releaseAuthorizationClaims(provider) {
+    const prototype = provider.Claims.prototype;
+    const scope = prototype.scope;
+    const result = prototype.result;
+    prototype.scope = function (value) {
+        maskScopes.set(this, value ?? '');
+        return scope.call(this, value);
+    };
+    prototype.result = async function () {
+        const claims = await result.call(this);
+        const present = PERMISSION_CLAIMS.filter((name) => name in this.available);
+        if (present.some((name) => !(name in claims))) {
+            for (const name of present) {
+                delete claims[name];
+            }
+        }
+        const custom = this.available[CUSTOM_CLAIMS];
+        if (!custom || !scopesOf(maskScopes.get(this)).has(CUSTOM_CLAIMS_SCOPE)) {
+            return claims;
+        }
+        return { ...custom, ...claims };
+    };
+}
+//# sourceMappingURL=accountClaims.js.map

package/dist/accountClaims.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"accountClaims.js","sourceRoot":"","sources":["../src/accountClaims.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,OAAO,EACL,mBAAmB,EAEnB,uBAAuB,GACxB,MAAM,sBAAsB,CAAC;AAG9B;;;;GAIG;AACH,MAAM,CAAC,MAAM,yBAAyB,GAAG,uBAAuB,CAAC;AAIjE,+FAA+F;AAC/F,MAAM,CAAC,MAAM,iBAAiB,GAAG,aAAa,CAAC;AAC/C,wEAAwE;AACxE,MAAM,CAAC,MAAM,mBAAmB,GAAG,eAAe,CAAC;AAEnD,4FAA4F;AAC5F,MAAM,CAAC,MAAM,iBAAiB,GAAG;IAC/B,aAAa;IACb,qBAAqB;IACrB,WAAW;IACX,iBAAiB;CACT,CAAC;AAEX,MAAM,CAAC,MAAM,wBAAwB,GAAG,CAAC,OAAO,EAAE,QAAQ,EAAE,GAAG,iBAAiB,CAAC,CAAC;AAElF,yFAAyF;AACzF,2BAA2B;AAC3B,MAAM,aAAa,GAAG,MAAM,CAAC,uBAAuB,CAAC,CAAC;AACtD,MAAM,gBAAgB,GAAG,iBAAiB,CAAC;AAE3C,+FAA+F;AAC/F,MAAM,UAAU,cAAc,CAAC,OAA4B;IACzD,OAAO,MAAM,CAAC,WAAW,CACvB,MAAM,CAAC,OAAO,CAAC,OAAO,CAAC,YAAY,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,IAAI,CAAC,EAAE,EAAE,CAAC,CAAC,mBAAmB,CAAC,IAAI,CAAC,CAAC,CACpF,CAAC;AACJ,CAAC;AAED,SAAS,gBAAgB,CAAC,OAA4B;IACpD,MAAM,EAAE,MAAM,EAAE,GAAG,IAAI,EAAE,GAAG,OAAO,CAAC;IACpC,OAAQ,IAAqC,CAAC,YAAY,CAAC;IAC3D,OAAO,EAAE,GAAG,IAAI,EAAE,GAAG,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,CAAC;AACpD,CAAC;AAED,+FAA+F;AAC/F,MAAM,UAAU,eAAe,CAAC,OAA4B;IAC1D,OAAO;QACL,GAAG,gBAAgB,CAAC,OAAO,CAAC;QAC5B,GAAG,EAAE,OAAO,CAAC,GAAG;QAChB,CAAC,aAAa,CAAC,EAAE,cAAc,CAAC,OAAO,CAAC;KACzC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,WAAW,CAAC,OAAgB,EAAE,MAA2B;IACvE,OAAO,MAAM,CAAC,MAAM,CAAC,OAAO,EAAE,EAAE,CAAC,gBAAgB,CAAC,EAAE,MAAM,EAAE,CAAC,CAAC;AAChE,CAAC;AAED,MAAM,UAAU,iBAAiB,CAAC,OAAgB;IAChD,MAAM,KAAK,GAAI,OAA+C,EAAE,CAAC,gBAAgB,CAAC,CAAC;IACnF,OAAO,KAAK,CAAC,CAAC,CAAE,KAA6B,CAAC,CAAC,CAAC,SAAS,CAAC;AAC5D,CAAC;AAED,SAAS,QAAQ,CAAC,KAAc;IAC9B,OAAO,IAAI,GAAG,CAAC,OAAO,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;AACpE,CAAC;AAED,wFAAwF;AACxF,MAAM,UAAU,sBAAsB,CACpC,OAA4B,EAC5B,KAAc;IAEd,MAAM,MAAM,GAAG,QAAQ,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,QAAQ,GAAG,gBAAgB,CAAC,OAAO,CAAC,CAAC;IAC3C,OAAO;QACL,GAAG,CAAC,MAAM,CAAC,GAAG,CAAC,mBAAmB,CAAC,CAAC,CAAC,CAAC,cAAc,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;QACnE,GAAG,CAAC,MAAM,CAAC,GAAG,CAAC,iBAAiB,CAAC;YAC/B,CAAC,CAAC,MAAM,CAAC,WAAW,CAChB,wBAAwB,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,IAAI,QAAQ,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC;gBACxE,IAAI;gBACJ,QAAQ,CAAC,IAAI,CAAC;aACf,CAAC,CACH;YACH,CAAC,CAAC,EAAE,CAAC;KACR,CAAC;AACJ,CAAC;AAQD,MAAM,UAAU,GAAG,IAAI,OAAO,EAAkB,CAAC;AAEjD;;;;;;;GAOG;AACH,MAAM,UAAU,0BAA0B,CAAC,QAAkB;IAC3D,MAAM,SAAS,GAAG,QAAQ,CAAC,MAAM,CAAC,SAAkC,CAAC;IACrE,MAAM,KAAK,GAAG,SAAS,CAAC,KAAK,CAAC;IAC9B,MAAM,MAAM,GAAG,SAAS,CAAC,MAAM,CAAC;IAChC,SAAS,CAAC,KAAK,GAAG,UAA4B,KAAc;QAC1D,UAAU,CAAC,GAAG,CAAC,IAAI,EAAE,KAAK,IAAI,EAAE,CAAC,CAAC;QAClC,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,EAAE,KAAK,CAAC,CAAC;IACjC,CAAC,CAAC;IACF,SAAS,CAAC,MAAM,GAAG,KAAK;QACtB,MAAM,MAAM,GAAG,MAAM,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QACvC,MAAM,OAAO,GAAG,iBAAiB,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,IAAI,IAAI,CAAC,SAAS,CAAC,CAAC;QAC3E,IAAI,OAAO,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,IAAI,MAAM,CAAC,CAAC,EAAE,CAAC;YAC9C,KAAK,MAAM,IAAI,IAAI,OAAO,EAAE,CAAC;gBAC3B,OAAO,MAAM,CAAC,IAAI,CAAC,CAAC;YACtB,CAAC;QACH,CAAC;QACD,MAAM,MAAM,GAAG,IAAI,CAAC,SAAS,CAAC,aAAa,CAAwC,CAAC;QACpF,IAAI,CAAC,MAAM,IAAI,CAAC,QAAQ,CAAC,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,GAAG,CAAC,mBAAmB,CAAC,EAAE,CAAC;YACxE,OAAO,MAAM,CAAC;QAChB,CAAC;QACD,OAAO,EAAE,GAAG,MAAM,EAAE,GAAG,MAAM,EAAE,CAAC;IAClC,CAAC,CAAC;AACJ,CAAC"}

package/dist/adapter.js

@@ -5,7 +5,7 @@
  */
 import { randomBytes } from 'node:crypto';
 import { OidcPayloadModelSchema, } from '@seamless-auth/types';
-import { errors } from 'oidc-provider';
+import Provider, { errors } from 'oidc-provider';
 import { checkDeviceRequest, DEVICE_CODE_GRANT, DevicePollThrottle, isDeviceGrant, withLoginPrompt, } from './deviceFlow.js';
 import { adoptSession, currentRequestContext, markDeviceFlow, } from './requestContext.js';
 /** A client assertion or proof presented twice. Answered as `invalid_client`, not a 500. */
@@ -31,6 +31,11 @@ export class UnsupportedModelError extends Error {
 // made under, so they only fill an empty context. Every other record is the thing the request
 // is acting on.
 const CONTEXTUAL_MODELS = new Set(['Session', 'Grant']);
+/** The library's own test (`BaseToken#isExpired`): `exp` at or before now, in seconds. */
+function isExpired(record) {
+    const { exp } = record.payload;
+    return typeof exp === 'number' && exp <= Math.floor(Date.now() / 1000);
+}
 function toAdapterPayload(model, record) {
     if (!record) {
         return undefined;
@@ -82,6 +87,8 @@ export class ApiPayloadAdapter {
             }
             // ADR D10: never carried into the device's tokens, whatever the approver earned.
             delete stored.acr;
+            delete stored.amr;
+            delete stored.authTime;
         }
         const { created } = await this.#client.upsertPayload(model, id, {
             payload: stored,
@@ -99,8 +106,16 @@ export class ApiPayloadAdapter {
         const context = currentRequestContext();
         const record = await this.#client.findPayload(model, id);
         // The grant loads the code more than once per request, and only the first is the poll.
-        // Only a code that exists is tracked, so made-up ones cannot fill the throttle.
-        if (model === 'DeviceCode' && record && context?.tokenRequest && !context.devicePolled) {
+        // Only a live code that exists is tracked, so made-up ones cannot fill the throttle, and
+        // an expired one the API still returns gets the library's expired_token, not slow_down.
+        // The library's own routing says whether this is the token endpoint, for every spelling
+        // of the path it accepts.
+        if (model === 'DeviceCode' &&
+            record &&
+            !isExpired(record) &&
+            context &&
+            !context.devicePolled &&
+            Provider.ctx?.oidc?.route === 'token') {
             context.devicePolled = true;
             this.#polls.check(id);
         }
@@ -124,9 +139,15 @@ export class ApiPayloadAdapter {
     /**
      * A refresh carries the acr, amr and auth_time of the session's current row, not the ones
      * the token was first issued with: a step-up since then moved them, and `/oidc/sign`
-     * refuses any value that differs from the row.
+     * refuses any value that differs from the row. A device grant carries none (ADR D10).
      */
     async #adoptCurrentAuthContext(payload, sessionId) {
+        if (isDeviceGrant(payload)) {
+            delete payload.acr;
+            delete payload.amr;
+            delete payload.authTime;
+            return;
+        }
         const { clientId, accountId } = payload;
         if (typeof clientId !== 'string') {
             return;
@@ -136,7 +157,7 @@ export class ApiPayloadAdapter {
             return;
         }
         payload.authTime = context.authTime;
-        if (context.acr && !isDeviceGrant(payload)) {
+        if (context.acr) {
             payload.acr = context.acr;
         }
         else {