authhero 9.8.0 → 9.9.1

package/dist/types/authentication-flows/grant-tokens.d.ts

@@ -0,0 +1,16 @@
+import { Context } from "hono";
+import { GrantType, TokenResponse } from "@authhero/adapter-interfaces";
+import { Bindings, Variables } from "../types";
+import { GrantFlowResult } from "../types/GrantFlowResult";
+/**
+ * Turn a resolved grant into wire tokens: narrow the requested scopes to what
+ * the user/client is actually granted for the audience, pick the token
+ * lifetime from the resource server, then mint the tokens.
+ *
+ * Shared by the /oauth/token endpoint and the server-side code exchange on the
+ * /u2/info test page so both mint identical tokens for the same grant.
+ */
+export declare function issueTokensForGrant(ctx: Context<{
+    Bindings: Bindings;
+    Variables: Variables;
+}>, grantResult: GrantFlowResult, grantType: GrantType): Promise<TokenResponse>;

package/dist/types/authentication-flows/passwordless.d.ts

@@ -1,10 +1,13 @@
 import { Context } from "hono";
 import { z } from "@hono/zod-openapi";
 import { Bindings, Variables } from "../types";
+import { GrantFlowUserResult } from "../types/GrantFlowResult";
 export declare const passwordlessGrantParamsSchema: z.ZodObject<{
     client_id: z.ZodString;
     username: z.ZodPipe<z.ZodString, z.ZodTransform<string, string>>;
     otp: z.ZodString;
+    scope: z.ZodOptional<z.ZodString>;
+    audience: z.ZodOptional<z.ZodString>;
     authParams: z.ZodOptional<z.ZodObject<{
         client_id: z.ZodString;
         act_as: z.ZodOptional<z.ZodString>;
@@ -42,7 +45,7 @@ export declare const passwordlessGrantParamsSchema: z.ZodObject<{
 export declare function passwordlessGrantUser(ctx: Context<{
     Bindings: Bindings;
     Variables: Variables;
-}>, { client_id, username, otp, authParams, enforceIpCheck, }: z.input<typeof passwordlessGrantParamsSchema>): Promise<{
+}>, { client_id, username, otp, scope, audience, authParams, enforceIpCheck, }: z.input<typeof passwordlessGrantParamsSchema>): Promise<{
     user: {
         connection: string;
         email_verified: boolean;
@@ -558,16 +561,16 @@ export declare function passwordlessGrantUser(ctx: Context<{
     authConnection: "username" | "email" | "sms";
     session_id: string | undefined;
     authParams: {
+        audience?: string | undefined;
+        scope?: string | undefined;
         client_id: string;
         act_as?: string | undefined;
         response_type?: import("@authhero/adapter-interfaces").AuthorizationResponseType | undefined;
         response_mode?: import("@authhero/adapter-interfaces").AuthorizationResponseMode | undefined;
         redirect_uri?: string | undefined;
-        audience?: string | undefined;
         organization?: string | undefined;
         state?: string | undefined;
         nonce?: string | undefined;
-        scope?: string | undefined;
         prompt?: string | undefined;
         code_challenge_method?: import("@authhero/adapter-interfaces").CodeChallengeMethod | undefined;
         code_challenge?: string | undefined;
@@ -590,6 +593,26 @@ export declare function passwordlessGrantUser(ctx: Context<{
         vendor_id?: string | undefined;
     };
 }>;
+/**
+ * The `http://auth0.com/oauth/grant-type/passwordless/otp` grant at
+ * /oauth/token.
+ *
+ * Unlike the authorization-code exchange — where /authorize has already
+ * authenticated the login session and created a session — nothing has run for
+ * this login yet: /passwordless/start only stores a PENDING login session and
+ * an OTP. So authenticate it here, which creates the session the auth cookie
+ * and the refresh token below both hang off, then mint a refresh token when
+ * `offline_access` was requested (issue #1273).
+ *
+ * The sibling front-channel path (`passwordlessGrant`, used by
+ * /co/authenticate) does not go through here: createFrontChannelAuthResponse
+ * does both steps itself, and skips the refresh token for code flows so the
+ * exchange issues it instead.
+ */
+export declare function passwordlessOtpGrant(ctx: Context<{
+    Bindings: Bindings;
+    Variables: Variables;
+}>, params: z.input<typeof passwordlessGrantParamsSchema>): Promise<GrantFlowUserResult>;
 export declare function passwordlessGrant(ctx: Context<{
     Bindings: Bindings;
     Variables: Variables;

package/dist/types/helpers/refresh-token-lifetime.d.ts

@@ -0,0 +1,103 @@
+/**
+ * Refresh-token lifetimes (issue #1260).
+ *
+ * Auth0 keeps refresh-token expiry and session expiry as two separate
+ * concepts: the former is configured per *client* (`client.refresh_token.*`,
+ * in seconds), the latter per *tenant* (`session_lifetime` /
+ * `idle_session_lifetime`, in hours). AuthHero historically derived
+ * refresh-token expiry from the tenant session lifetimes only, which made
+ * `infinite_token_lifetime` — the setting native/mobile clients rely on —
+ * unrepresentable.
+ *
+ * These helpers resolve the effective lifetime: per-client config wins when
+ * set, otherwise we fall back to the tenant-derived behaviour so existing
+ * tenants see no change.
+ */
+/**
+ * A resolved refresh-token lifetime.
+ *
+ * - `seconds` — expires this many seconds after the anchor point.
+ * - `infinite` — explicitly configured never to expire.
+ * - `unset` — nothing configured at either level. Distinct from `infinite`
+ *   so callers can tell "the operator asked for no expiry" from "no opinion":
+ *   at mint both mean no expiry, but on rotation only `infinite` clears an
+ *   expiry the parent row already carried.
+ */
+export type RefreshTokenLifetime = {
+    kind: "seconds";
+    seconds: number;
+} | {
+    kind: "infinite";
+} | {
+    kind: "unset";
+};
+/** The subset of a client this module reads. */
+export interface RefreshTokenLifetimeClient {
+    refresh_token?: {
+        expiration_type?: "expiring" | "non-expiring";
+        token_lifetime?: number;
+        infinite_token_lifetime?: boolean;
+        idle_token_lifetime?: number;
+        infinite_idle_token_lifetime?: boolean;
+    };
+    tenant: {
+        session_lifetime?: number;
+        idle_session_lifetime?: number;
+    };
+}
+/**
+ * Absolute ("hard") refresh-token lifetime: how long the token is valid for,
+ * regardless of use.
+ */
+export declare function resolveAbsoluteRefreshTokenLifetime(client: RefreshTokenLifetimeClient): RefreshTokenLifetime;
+/**
+ * Idle ("sliding") refresh-token lifetime: how long the token survives without
+ * being exchanged. Refreshed on every successful exchange.
+ */
+export declare function resolveIdleRefreshTokenLifetime(client: RefreshTokenLifetimeClient): RefreshTokenLifetime;
+/**
+ * Turn a lifetime into an ISO expiry timestamp measured from `from`.
+ * `infinite` and `unset` both yield `undefined` — no expiry column is written.
+ */
+export declare function lifetimeToExpiresAt(lifetime: RefreshTokenLifetime, from?: number): string | undefined;
+/**
+ * Both expiry timestamps for a freshly minted refresh token.
+ */
+export declare function resolveRefreshTokenExpiry(client: RefreshTokenLifetimeClient, from?: number): {
+    expires_at?: string;
+    idle_expires_at?: string;
+};
+/**
+ * The idle expiry a token should carry after a successful exchange.
+ *
+ * Sliding only applies to a token that already had an idle window: a row minted
+ * without one is not retro-fitted with an expiry mid-life. The exception is an
+ * explicit `infinite` config, which clears an existing window so a client
+ * switched to non-expiring stops being cut off by expiries stamped earlier.
+ */
+export declare function slideIdleExpiry(client: RefreshTokenLifetimeClient, currentIdleExpiresAt: string | undefined, from?: number): string | undefined;
+/**
+ * The expiry columns an in-place (non-rotating) exchange should write.
+ *
+ * Three-valued per column, matching the adapter's update contract:
+ * `undefined` leaves the stored value alone, a string overwrites it, `null`
+ * clears it.
+ *
+ * Rotation reconciles a changed client config for free — the child row is
+ * minted from the current lifetimes — but the non-rotating path keeps handing
+ * back the row it was given, so it has to say so explicitly:
+ *
+ * - Idle window: slides by the resolved lifetime, and is cleared when the
+ *   client is configured never to idle-expire. A row minted without an idle
+ *   window is not retro-fitted with one mid-life.
+ * - Absolute window: never extended — refreshing must not let a bounded token
+ *   outlive the expiry stamped at mint — and only cleared when the client is
+ *   configured never to expire.
+ */
+export declare function resolveExchangeExpiryUpdate(client: RefreshTokenLifetimeClient, current: {
+    expires_at?: string;
+    idle_expires_at?: string;
+}, from?: number): {
+    expires_at?: null;
+    idle_expires_at?: string | null;
+};

package/dist/types/helpers/revoke-session-refresh-tokens.d.ts

@@ -0,0 +1,33 @@
+import { DataAdapters } from "@authhero/adapter-interfaces";
+/**
+ * The parts of a session this cascade needs: its own id, which refresh tokens
+ * point at through `session_id`, and the login session it originated from,
+ * which is the only link rows minted before that column existed carry.
+ */
+export interface RevocableSession {
+    id: string;
+    login_session_id?: string;
+}
+/**
+ * Revoke every refresh token issued under a session.
+ *
+ * Call this only where a session is *deliberately* ended — an admin revoking
+ * or deleting it, or a user being blocked. Natural expiry and cleanup must not
+ * cascade: a refresh token is designed to outlive its session, and killing
+ * tokens on an SSO timeout would log out every long-lived native client on
+ * each timeout. Revocation couples; lifetime does not.
+ *
+ * Two sweeps, run in sequence:
+ *
+ * 1. `session_id` — the ownership edge, and the one that is actually complete.
+ * 2. `login_id` — legacy fallback for rows minted before `session_id` existed.
+ *    `sessions.login_session_id` records only the session's *originating*
+ *    authorization transaction and is never repointed on SSO reuse, so on its
+ *    own it misses every token minted during a later re-authorization. It is
+ *    retained until pre-Stage-2 rows have aged out (#1259) and then dropped.
+ *
+ * Sequential rather than parallel because a row can match both predicates, and
+ * both adapters guard on `revoked_at IS NULL` — so the second sweep skips what
+ * the first already revoked instead of double-counting it.
+ */
+export declare function revokeSessionRefreshTokens(data: DataAdapters, tenant_id: string, session: RevocableSession, revoked_at: string): Promise<number>;

package/dist/types/hooks/addDataHooks.d.ts

@@ -10,9 +10,10 @@ import { Bindings, Variables } from "../types";
  * dispatch post-event outbox messages. `users.rawCreate` is NOT decorated —
  * commit paths call it directly to bypass the hook layer by design.
  *
- * `email` is lowercased on the way in so the pre-commit hooks and lookups
- * (`preUserSignupHook`, the email→primary linking query) see the same
- * normalized value that will be stored. Hooks can assign `email` themselves
+ * `email` is normalized (trimmed and lowercased) on the way in so the
+ * pre-commit hooks and lookups (`preUserSignupHook`, the email→primary linking
+ * query) see the same normalized value that will be stored. Hooks can assign
+ * `email` themselves
  * after this point, so the decorators normalize again just before their
  * commit — see `createUserHooks` / `createUserUpdateHooks`.
  */