@frontmcp/sdk 0.6.0 → 0.6.2

package/src/auth/jwks/jwks.utils.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"jwks.utils.js","sourceRoot":"","sources":["../../../../src/auth/jwks/jwks.utils.ts"],"names":[],"mappings":";;AAAA,8BAEC;AACD,0CAEC;AAGD,oDAgBC;AAxBD,SAAgB,SAAS,CAAC,CAAS;IACjC,OAAO,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC;AACvC,CAAC;AACD,SAAgB,eAAe,CAAC,CAAU;IACxC,OAAO,SAAS,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC;AACpC,CAAC;AAED,uEAAuE;AACvE,SAAgB,oBAAoB,CAAC,KAAc;IACjD,IAAI,CAAC,KAAK;QAAE,OAAO,SAAS,CAAC;IAC7B,MAAM,KAAK,GAAG,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;IAC/B,IAAI,KAAK,CAAC,MAAM,GAAG,CAAC;QAAE,OAAO,SAAS,CAAC;IACvC,IAAI,CAAC;QACH,MAAM,GAAG,GAAG,KAAK,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC;QAC3D,MAAM,IAAI,GACR,OAAO,MAAM,KAAK,WAAW;YAC3B,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,EAAE,QAAQ,CAAC,CAAC,QAAQ,CAAC,MAAM,CAAC;YAC7C,CAAC,CAAC,mBAAmB;gBACrB,IAAI,CAAC,GAAG,CAAC,CAAC;QACd,MAAM,GAAG,GAAG,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;QAC7B,OAAO,GAAG,IAAI,OAAO,GAAG,KAAK,QAAQ,CAAC,CAAC,CAAE,GAA+B,CAAC,CAAC,CAAC,SAAS,CAAC;IACvF,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,SAAS,CAAC;IACnB,CAAC;AACH,CAAC","sourcesContent":["export function trimSlash(s: string) {\n  return (s ?? '').replace(/\\/+$/, '');\n}\nexport function normalizeIssuer(u?: string) {\n  return trimSlash(String(u ?? ''));\n}\n\n/** Safe, no-verify JWT payload decode (returns undefined on error). */\nexport function decodeJwtPayloadSafe(token?: string): Record<string, unknown> | undefined {\n  if (!token) return undefined;\n  const parts = token.split('.');\n  if (parts.length < 2) return undefined;\n  try {\n    const b64 = parts[1].replace(/-/g, '+').replace(/_/g, '/');\n    const json =\n      typeof Buffer !== 'undefined'\n        ? Buffer.from(b64, 'base64').toString('utf8')\n        : // browser fallback\n        atob(b64);\n    const obj = JSON.parse(json);\n    return obj && typeof obj === 'object' ? (obj as Record<string, unknown>) : undefined;\n  } catch {\n    return undefined;\n  }\n}\n"]}

package/src/auth/machine-id.js

@@ -1,32 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.getMachineId = getMachineId;
-// auth/machine-id.ts
-// Single source of truth for the machine ID used across session management
-const crypto_1 = require("crypto");
-/**
- * Single-process machine ID generated at server launch.
- * Used for:
- * - Session encryption key derivation
- * - Session validation (nodeId matching)
- *
- * All session-related modules should import getMachineId from this module
- * to ensure consistency across the application.
- *
- * IMPORTANT: If MACHINE_ID env var is not set, a random UUID is generated
- * on each restart, invalidating all existing sessions. In production with
- * multiple instances, set MACHINE_ID to enable session portability across
- * nodes, or use instance-specific IDs to enforce session affinity.
- */
-const MACHINE_ID = (() => {
-    // Prefer an injected env (stable across restarts) if you have one; else random per launch
-    return process.env['MACHINE_ID'] || (0, crypto_1.randomUUID)();
-})();
-/**
- * Get the current machine ID.
- * This value is stable for the lifetime of the process.
- */
-function getMachineId() {
-    return MACHINE_ID;
-}
-//# sourceMappingURL=machine-id.js.map

package/src/auth/machine-id.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"machine-id.js","sourceRoot":"","sources":["../../../src/auth/machine-id.ts"],"names":[],"mappings":";;AA2BA,oCAEC;AA7BD,qBAAqB;AACrB,2EAA2E;AAC3E,mCAAoC;AAEpC;;;;;;;;;;;;;GAaG;AACH,MAAM,UAAU,GAAG,CAAC,GAAG,EAAE;IACvB,0FAA0F;IAC1F,OAAO,OAAO,CAAC,GAAG,CAAC,YAAY,CAAC,IAAI,IAAA,mBAAU,GAAE,CAAC;AACnD,CAAC,CAAC,EAAE,CAAC;AAEL;;;GAGG;AACH,SAAgB,YAAY;IAC1B,OAAO,UAAU,CAAC;AACpB,CAAC","sourcesContent":["// auth/machine-id.ts\n// Single source of truth for the machine ID used across session management\nimport { randomUUID } from 'crypto';\n\n/**\n * Single-process machine ID generated at server launch.\n * Used for:\n * - Session encryption key derivation\n * - Session validation (nodeId matching)\n *\n * All session-related modules should import getMachineId from this module\n * to ensure consistency across the application.\n *\n * IMPORTANT: If MACHINE_ID env var is not set, a random UUID is generated\n * on each restart, invalidating all existing sessions. In production with\n * multiple instances, set MACHINE_ID to enable session portability across\n * nodes, or use instance-specific IDs to enforce session affinity.\n */\nconst MACHINE_ID = (() => {\n  // Prefer an injected env (stable across restarts) if you have one; else random per launch\n  return process.env['MACHINE_ID'] || randomUUID();\n})();\n\n/**\n * Get the current machine ID.\n * This value is stable for the lifetime of the process.\n */\nexport function getMachineId(): string {\n  return MACHINE_ID;\n}\n"]}

package/src/auth/oauth/flows/oauth.authorize.flow.js

@@ -1,33 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * Authorization Endpoint — GET /oauth/authorize
- *
- * Who calls: Browser via the Client (RP).
- *
- * When: Start of the flow.
- *
- * Purpose: Authenticate the user and obtain consent; returns an authorization code to the client’s redirect URI.
- *
- * Notes: Must support PKCE. Implicit/Hybrid are out in OAuth 2.1.
- */
-/**
- * Typical parameter shapes
- *
- * /oauth/authorize (GET)
- *
- * response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256, (optionally request_uri from PAR)
- */
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-//# sourceMappingURL=oauth.authorize.flow.js.map

package/src/auth/oauth/flows/oauth.authorize.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oauth.authorize.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oauth.authorize.flow.ts"],"names":[],"mappings":";;AAAA;;;;;;;;;;GAUG;AACH;;;;;;GAMG;AACH;;;;;;;;;;;GAWG","sourcesContent":["/**\n * Authorization Endpoint — GET /oauth/authorize\n *\n * Who calls: Browser via the Client (RP).\n *\n * When: Start of the flow.\n *\n * Purpose: Authenticate the user and obtain consent; returns an authorization code to the client’s redirect URI.\n *\n * Notes: Must support PKCE. Implicit/Hybrid are out in OAuth 2.1.\n */\n/**\n * Typical parameter shapes\n *\n * /oauth/authorize (GET)\n *\n * response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256, (optionally request_uri from PAR)\n */\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n"]}

package/src/auth/oauth/flows/oauth.device-authorization.flow.js

@@ -1,48 +0,0 @@
-"use strict";
-/**
- * Device Authorization — POST /oauth/device_authorization
- *
- * Who calls: Device/TV app.
- *
- * Purpose: Start the device flow (user completes authorization on a second screen).
- */
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-/**
- *
- * OAuth 2.0 Device Authorization Grant (“device code flow”)
- * Who does what (at a glance)
- *
- * Device/TV/CLI (no browser)
- * Calls POST /oauth/device_authorization, shows the user a code + URL, and polls POST /oauth/token.
- *
- * User (on phone/laptop browser)
- * Visits the given verification_uri and authenticates using your normal OAuth login (whatever you already have). No new UI required beyond two tiny endpoints.
- *
- * Auth Server (you)
- * Stores the device transaction and, after the user authenticates, marks it as approved so the device’s /oauth/token polling succeeds.
- *
- * Endpoints you need (only two “new” ones)
- *
- * POST /oauth/device_authorization ✅ (device calls)
- *
- * POST /oauth/token with grant urn:ietf:params:oauth:grant-type:device_code ✅ (device polls)
- *
- * GET /activate ➜ “UI handler” (user lands here from verification_uri — this just redirects into your existing /oauth/authorize)
- *
- * GET /activate/callback ➜ “UI handler” (your existing flow returns here after the user logs in; you flip the device record to approved and show a basic “All set” page)
- *
- * That’s it. No pages with complex consent screens are required; reuse your normal /oauth/authorize
- */
-//# sourceMappingURL=oauth.device-authorization.flow.js.map

package/src/auth/oauth/flows/oauth.device-authorization.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oauth.device-authorization.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oauth.device-authorization.flow.ts"],"names":[],"mappings":";AAAA;;;;;;GAMG;;AAEH;;;;;;;;;;;GAWG;AAEH;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG","sourcesContent":["/**\n * Device Authorization — POST /oauth/device_authorization\n *\n * Who calls: Device/TV app.\n *\n * Purpose: Start the device flow (user completes authorization on a second screen).\n */\n\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n\n/**\n *\n * OAuth 2.0 Device Authorization Grant (“device code flow”)\n * Who does what (at a glance)\n *\n * Device/TV/CLI (no browser)\n * Calls POST /oauth/device_authorization, shows the user a code + URL, and polls POST /oauth/token.\n *\n * User (on phone/laptop browser)\n * Visits the given verification_uri and authenticates using your normal OAuth login (whatever you already have). No new UI required beyond two tiny endpoints.\n *\n * Auth Server (you)\n * Stores the device transaction and, after the user authenticates, marks it as approved so the device’s /oauth/token polling succeeds.\n *\n * Endpoints you need (only two “new” ones)\n *\n * POST /oauth/device_authorization ✅ (device calls)\n *\n * POST /oauth/token with grant urn:ietf:params:oauth:grant-type:device_code ✅ (device polls)\n *\n * GET /activate ➜ “UI handler” (user lands here from verification_uri — this just redirects into your existing /oauth/authorize)\n *\n * GET /activate/callback ➜ “UI handler” (your existing flow returns here after the user logs in; you flip the device record to approved and show a basic “All set” page)\n *\n * That’s it. No pages with complex consent screens are required; reuse your normal /oauth/authorize\n */\n"]}

package/src/auth/oauth/flows/oauth.introspect.flow.js

@@ -1,28 +0,0 @@
-"use strict";
-/**
- * Token Introspection — POST /oauth/introspect
- *
- * Who calls: Resource servers (API gateways).
- *
- * Purpose: Check if a token is active and fetch metadata (subject, scopes, expiry)
- * when you use opaque tokens or want server-side validation (RFC 7662).
- */
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * Typical parameter shapes
- *
- * /oauth/introspect (POST): token, optional token_type_hint
- */
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-//# sourceMappingURL=oauth.introspect.flow.js.map

package/src/auth/oauth/flows/oauth.introspect.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oauth.introspect.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oauth.introspect.flow.ts"],"names":[],"mappings":";AAAA;;;;;;;GAOG;;AAEH;;;;GAIG;AACH;;;;;;;;;;;GAWG","sourcesContent":["/**\n * Token Introspection — POST /oauth/introspect\n *\n * Who calls: Resource servers (API gateways).\n *\n * Purpose: Check if a token is active and fetch metadata (subject, scopes, expiry)\n * when you use opaque tokens or want server-side validation (RFC 7662).\n */\n\n/**\n * Typical parameter shapes\n *\n * /oauth/introspect (POST): token, optional token_type_hint\n */\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n"]}

package/src/auth/oauth/flows/oauth.par.flow.js

@@ -1,29 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * Pushed Authorization Requests (PAR) — POST /oauth/par
- *
- * Who calls: Client (before sending user to /authorize).
- *
- * Purpose: Client uploads the full authorization request; you return a request_uri the client forwards to /authorize.
- *
- * Why: Prevents parameter tampering and URL-length issues; recommended for high-security setups and with DPoP/JAR.
- */
-/**
- * Typical parameter shapes
-
- * /oauth/par (POST): same authz params as /authorize (client-authenticated), returns { request_uri, expires_in }
- */
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-//# sourceMappingURL=oauth.par.flow.js.map

package/src/auth/oauth/flows/oauth.par.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oauth.par.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oauth.par.flow.ts"],"names":[],"mappings":";;AAAA;;;;;;;;GAQG;AACH;;;;GAIG;AACH;;;;;;;;;;;GAWG","sourcesContent":["/**\n * Pushed Authorization Requests (PAR) — POST /oauth/par\n *\n * Who calls: Client (before sending user to /authorize).\n *\n * Purpose: Client uploads the full authorization request; you return a request_uri the client forwards to /authorize.\n *\n * Why: Prevents parameter tampering and URL-length issues; recommended for high-security setups and with DPoP/JAR.\n */\n/**\n * Typical parameter shapes\n\n * /oauth/par (POST): same authz params as /authorize (client-authenticated), returns { request_uri, expires_in }\n */\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n"]}

package/src/auth/oauth/flows/oauth.revoke.flow.js

@@ -1,27 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * Token Revocation — POST /oauth/revoke
- *
- * Who calls: Client.
- *
- * Purpose: Invalidate an access or refresh token early (RFC 7009).
- */
-/**
- * Typical parameter shapes
- *
- * /oauth/revoke (POST): token, token_type_hint=access_token|refresh_token
- */
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-//# sourceMappingURL=oauth.revoke.flow.js.map

package/src/auth/oauth/flows/oauth.revoke.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oauth.revoke.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oauth.revoke.flow.ts"],"names":[],"mappings":";;AAAA;;;;;;GAMG;AACH;;;;GAIG;AACH;;;;;;;;;;;GAWG","sourcesContent":["/**\n * Token Revocation — POST /oauth/revoke\n *\n * Who calls: Client.\n *\n * Purpose: Invalidate an access or refresh token early (RFC 7009).\n */\n/**\n * Typical parameter shapes\n *\n * /oauth/revoke (POST): token, token_type_hint=access_token|refresh_token\n */\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n"]}

package/src/auth/oauth/flows/oauth.token.flow.js

@@ -1,59 +0,0 @@
-"use strict";
-/**
- * Token Endpoint — POST /oauth/token
- *
- * Who calls: Client (server-to-server).
- *
- * When: After getting the code (or for refresh).
- *
- * Purpose: Exchange authorization code + PKCE verifier for access token (and optional refresh token), or refresh an access token.
- */
-/**
- * Typical parameter shapes
- *
- * /oauth/token (POST, application/x-www-form-urlencoded)
- *
- * For code exchange: grant_type=authorization_code, code, redirect_uri, client_id (and auth), code_verifier
- *
- * For refresh: grant_type=refresh_token, refresh_token, client_id (and auth)
- */
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- *
- * OAuth 2.0 Device Authorization Grant (“device code flow”)
- * Who does what (at a glance)
- *
- * Device/TV/CLI (no browser)
- * Calls POST /oauth/device_authorization, shows the user a code + URL, and polls POST /oauth/token.
- *
- * User (on phone/laptop browser)
- * Visits the given verification_uri and authenticates using your normal OAuth login (whatever you already have). No new UI required beyond two tiny endpoints.
- *
- * Auth Server (you)
- * Stores the device transaction and, after the user authenticates, marks it as approved so the device’s /oauth/token polling succeeds.
- *
- * Endpoints you need (only two “new” ones)
- *
- * POST /oauth/device_authorization ✅ (device calls)
- *
- * POST /oauth/token with grant urn:ietf:params:oauth:grant-type:device_code ✅ (device polls)
- *
- * GET /activate ➜ “UI handler” (user lands here from verification_uri — this just redirects into your existing /oauth/authorize)
- *
- * GET /activate/callback ➜ “UI handler” (your existing flow returns here after the user logs in; you flip the device record to approved and show a basic “All set” page)
- *
- * That’s it. No pages with complex consent screens are required; reuse your normal /oauth/authorize
- */
-//# sourceMappingURL=oauth.token.flow.js.map

package/src/auth/oauth/flows/oauth.token.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oauth.token.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oauth.token.flow.ts"],"names":[],"mappings":";AAAA;;;;;;;;GAQG;AACH;;;;;;;;GAQG;AACH;;;;;;;;;;;GAWG;;AAEH;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG","sourcesContent":["/**\n * Token Endpoint — POST /oauth/token\n *\n * Who calls: Client (server-to-server).\n *\n * When: After getting the code (or for refresh).\n *\n * Purpose: Exchange authorization code + PKCE verifier for access token (and optional refresh token), or refresh an access token.\n */\n/**\n * Typical parameter shapes\n *\n * /oauth/token (POST, application/x-www-form-urlencoded)\n *\n * For code exchange: grant_type=authorization_code, code, redirect_uri, client_id (and auth), code_verifier\n *\n * For refresh: grant_type=refresh_token, refresh_token, client_id (and auth)\n */\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n\n/**\n *\n * OAuth 2.0 Device Authorization Grant (“device code flow”)\n * Who does what (at a glance)\n *\n * Device/TV/CLI (no browser)\n * Calls POST /oauth/device_authorization, shows the user a code + URL, and polls POST /oauth/token.\n *\n * User (on phone/laptop browser)\n * Visits the given verification_uri and authenticates using your normal OAuth login (whatever you already have). No new UI required beyond two tiny endpoints.\n *\n * Auth Server (you)\n * Stores the device transaction and, after the user authenticates, marks it as approved so the device’s /oauth/token polling succeeds.\n *\n * Endpoints you need (only two “new” ones)\n *\n * POST /oauth/device_authorization ✅ (device calls)\n *\n * POST /oauth/token with grant urn:ietf:params:oauth:grant-type:device_code ✅ (device polls)\n *\n * GET /activate ➜ “UI handler” (user lands here from verification_uri — this just redirects into your existing /oauth/authorize)\n *\n * GET /activate/callback ➜ “UI handler” (your existing flow returns here after the user logs in; you flip the device record to approved and show a basic “All set” page)\n *\n * That’s it. No pages with complex consent screens are required; reuse your normal /oauth/authorize\n */\n"]}

package/src/auth/oauth/flows/oauth.userinfo.flow.js

@@ -1,24 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * UserInfo (OIDC) — GET/POST /oauth/userinfo (Only if you add OpenID Connect)
- *
- * Who calls: Client with access token.
- *
- * Purpose: Return standard user claims.
- *
- * Note: Requires the openid scope; if you do OIDC, also expose /.well-known/openid-configuration (separate from OAuth discovery).
- */
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-//# sourceMappingURL=oauth.userinfo.flow.js.map

package/src/auth/oauth/flows/oauth.userinfo.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oauth.userinfo.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oauth.userinfo.flow.ts"],"names":[],"mappings":";;AAAA;;;;;;;;GAQG;AACH;;;;;;;;;;;GAWG","sourcesContent":["/**\n * UserInfo (OIDC) — GET/POST /oauth/userinfo (Only if you add OpenID Connect)\n *\n * Who calls: Client with access token.\n *\n * Purpose: Return standard user claims.\n *\n * Note: Requires the openid scope; if you do OIDC, also expose /.well-known/openid-configuration (separate from OAuth discovery).\n */\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n"]}

package/src/auth/oauth/flows/oidc.logout.flow.js

@@ -1,20 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-/**
- * Session/Logout (OIDC) — e.g., GET /oidc/logout (front-/back-channel variants)
- *
- * Purpose: Coordinate RP logout if you support OIDC logout.
- */
-/**
- * Quick checklist (security & correctness)
- * - PKCE (S256) required for public clients (and basically for all).
- * - Use authorization code grant only (no implicit/hybrid).
- * - Rotate refresh tokens and bind them to client + user + scopes.
- * - Prefer private_key_jwt or mTLS for confidential clients.
- * - PAR + JAR recommended for higher security.
- * - Consider DPoP (proof-of-possession) to reduce token replay.
- * - Keep codes very short-lived (e.g., ≤60 s) and single-use.
- * - Publish discovery and JWKS, rotate keys safely.
- * - Decide JWT vs opaque access tokens; provide introspection if opaque.
- */
-//# sourceMappingURL=oidc.logout.flow.js.map

package/src/auth/oauth/flows/oidc.logout.flow.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"oidc.logout.flow.js","sourceRoot":"","sources":["../../../../../src/auth/oauth/flows/oidc.logout.flow.ts"],"names":[],"mappings":";;AAAA;;;;GAIG;AACH;;;;;;;;;;;GAWG","sourcesContent":["/**\n * Session/Logout (OIDC) — e.g., GET /oidc/logout (front-/back-channel variants)\n *\n * Purpose: Coordinate RP logout if you support OIDC logout.\n */\n/**\n * Quick checklist (security & correctness)\n * - PKCE (S256) required for public clients (and basically for all).\n * - Use authorization code grant only (no implicit/hybrid).\n * - Rotate refresh tokens and bind them to client + user + scopes.\n * - Prefer private_key_jwt or mTLS for confidential clients.\n * - PAR + JAR recommended for higher security.\n * - Consider DPoP (proof-of-possession) to reduce token replay.\n * - Keep codes very short-lived (e.g., ≤60 s) and single-use.\n * - Publish discovery and JWKS, rotate keys safely.\n * - Decide JWT vs opaque access tokens; provide introspection if opaque.\n */\n"]}