import type { SitecoreApiClientOptions } from "./types.js";
export type AccessTokenResult = {
    accessToken: string;
    refreshToken?: string;
    expiresIn?: number;
    tokenType?: string;
};
export type DeviceAuthorizationResult = {
    deviceCode: string;
    userCode?: string;
    verificationUri: string;
    verificationUriComplete?: string;
    expiresIn: number;
    interval: number;
    message?: string;
};
export declare const requestDeviceAuthorization: (environment: SitecoreApiClientOptions, scope?: string) => Promise<DeviceAuthorizationResult>;
export declare const pollDeviceToken: (environment: SitecoreApiClientOptions, device: DeviceAuthorizationResult) => Promise<AccessTokenResult>;
/**
 * Default OAuth audience for Sitecore Cloud APIs (Deploy + Authoring +
 * Sites). When the env profile doesn't pin an explicit `audience`,
 * Auth0 falls back to whatever default is configured for the M2M
 * client. Some org-scoped clients are configured with internal-only
 * audiences they aren't authorized to mint tokens for, so we always
 * send this audience explicitly on the request.
 */
export declare const DEFAULT_SITECORE_API_AUDIENCE = "https://api.sitecorecloud.io";
export declare const requestClientCredentialsToken: (environment: SitecoreApiClientOptions, scope?: string) => Promise<AccessTokenResult>;
export declare const requestPasswordToken: (environment: SitecoreApiClientOptions, username: string, password: string, scope?: string) => Promise<AccessTokenResult>;
/**
 * Pure OAuth acquisition: refresh-token-on-env, then client-credentials.
 * Does NOT touch the keychain token cache, and does NOT return the env's
 * embedded `accessToken` literal — callers wanting the literal-or-acquired
 * union should check `environment.accessToken` themselves first.
 *
 * The client-credentials mint fires whenever a `{ clientId, clientSecret }`
 * pair resolves through the shared three-tier chain — the
 * `SITECOREAI_ENV_<ENV>_CLIENT_SECRET` env var (bring-your-own-client),
 * the env-scoped automation client (`automationClient` block + the
 * `cm-client:<env>` keychain secret), or the org-scoped automation
 * client. A resolvable automation client IS the acquisition path: there
 * is no separate opt-in flag. `useClientCredentials` survives only as a
 * config-file marker for the bring-your-own-client hatch — `setup env`
 * mints an automation client without it, and that client must still
 * work. (This was the bug: the mint was gated on `useClientCredentials`,
 * so a scai-minted automation client could never produce a CM token.)
 *
 * Resolving that pair reads the OS keychain for the long-lived client
 * secret — the one keychain touch here; the short-lived token cache is
 * never read or written by this function (that is `getAccessToken`'s job).
 *
 * Library callers (orchestrators, MCP servers, tests) that bring their
 * own token cache should call this directly. The CLI uses `getAccessToken`
 * which adds keychain-backed caching on top.
 */
export declare const acquireAccessToken: (environment: SitecoreApiClientOptions) => Promise<AccessTokenResult | undefined>;
export declare const getAccessToken: (environment: SitecoreApiClientOptions) => Promise<string | undefined>;