/**
 * Auth0 OAuth 2.0 Device Authorization Flow client (RFC 8628).
 *
 * Used by `log10x_signin_start` (step 1: requestDeviceCode) and
 * `log10x_signin_complete` (step 2: pollForAccessToken). The flow:
 *
 *   1. POST `{AUTH0_DOMAIN}/oauth/device/code` with the public client_id
 *      → get back `device_code`, `user_code`, `verification_uri`,
 *        `verification_uri_complete`, `interval`, `expires_in`.
 *   2. The MCP shows the user the verification URL (Auth0 already
 *      embeds the user_code in `verification_uri_complete`) and
 *      launches their browser to it.
 *   3. The user lands on Auth0's universal login page where they pick
 *      GitHub, Google, or any other social/db connection enabled on
 *      the `mcp_backend` Auth0 client. They complete the chosen IdP's
 *      OAuth, Auth0 mints a session, then prompts them to confirm the
 *      device authorization.
 *   4. Poll `{AUTH0_DOMAIN}/oauth/token` every `interval` seconds with
 *      `grant_type=urn:ietf:params:oauth:grant-type:device_code`. Auth0
 *      responds with `authorization_pending` (HTTP 403) until the user
 *      confirms, then 200 + `access_token`/`id_token`/`refresh_token`.
 *
 * The Auth0 client must be of `app_type=native` and have the device_code
 * grant enabled. Client_id is public per RFC 8628 (appears in the
 * verification URL the user sees in their browser).
 *
 * References:
 *   - https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow
 *   - https://datatracker.ietf.org/doc/html/rfc8628
 */
/** Auth0 custom domain. Override via env for staging/forks. */
export declare const LOG10X_AUTH0_DOMAIN: string;
/** Auth0 native client id for the MCP. Public by design (appears in
 *  the user's verification URL during Device Flow). Override via env to
 *  point an MCP build at a different tenant (e.g. staging). */
export declare const LOG10X_AUTH0_CLIENT_ID: string;
/** Scopes for the device-code request.
 *  - `openid` is required for Auth0 to issue an ID token at all.
 *  - `profile` and `email` populate the standard OIDC claims so the
 *    backend's /userinfo lookup returns a real email + name.
 *  - `offline_access` requests a refresh_token so the user could
 *    re-issue access tokens later without going through Device Flow
 *    again. The MCP does not use it (the access_token is exchanged for a
 *    long-lived api_key and the Auth0 session is then forgotten), but it
 *    is cheap to ask for and lets other flows refresh without a fresh
 *    login.
 */
export declare const REQUESTED_SCOPES = "openid profile email offline_access";
export interface DeviceCodeResponse {
    device_code: string;
    user_code: string;
    verification_uri: string;
    /** Auth0 returns this with the user_code already embedded. Prefer
     *  it over manually building one. */
    verification_uri_complete: string;
    /** Seconds the device_code is valid; usually 900 (15 min). */
    expires_in: number;
    /** Minimum poll interval in seconds; usually 5. */
    interval: number;
}
export interface AccessTokenResponse {
    access_token: string;
    id_token?: string;
    refresh_token?: string;
    scope?: string;
    expires_in?: number;
    token_type: string;
}
/**
 * Step 1: ask Auth0 for a device + user code.
 */
export declare function requestDeviceCode(clientId?: string, scope?: string, domain?: string): Promise<DeviceCodeResponse>;
export interface PollOptions {
    deviceCode: string;
    /** Seconds between polls (from `requestDeviceCode`). */
    interval: number;
    /** Total polling deadline in seconds. */
    expiresIn: number;
    clientId?: string;
    domain?: string;
    /** Optional callback to log/render progress on each poll. */
    onTick?: (elapsedSec: number) => void;
}
/**
 * Step 2/3: poll until Auth0 returns an access token, the user declines,
 * or the device_code expires. Honors the `slow_down` back-pressure signal
 * by adding 5s to the interval each time.
 *
 * Auth0 returns these errors as HTTP 403 with a JSON body of
 * `{error: ..., error_description: ...}`. The 403 itself is not surfaced
 * as an error; the decision comes from the body's `error` field.
 */
export declare function pollForAccessToken(opts: PollOptions): Promise<AccessTokenResponse>;
/**
 * Refresh an expired Auth0 access token using a stored refresh token.
 * The device flow asks for `offline_access`, so signin always yields a
 * token at signin time. Refresh tokens are long-lived by default in
 * Auth0; access tokens typically last 24h.
 *
 * Returns the new access token + (optionally) a rotated refresh token.
 * Auth0 may issue a new refresh_token on each refresh — callers should
 * persist whichever value is returned to keep the chain alive.
 */
export declare function refreshAuth0AccessToken(refreshToken: string, clientId?: string, domain?: string): Promise<AccessTokenResponse>;