auth.provider API
    Preparing search index...

    RFC 7662 §2.2 token introspection response. Pulled into a typed interface (was inline JSON) so consumers (e.g. auth.proxy validation layer) can import type { IntrospectResponse } from "@o3co/auth- provider-oauth" and so the cnf claim has a documented home. See Wave 2 Token-binding Cluster spec §4.6.

    RFC 7662 §2.2 optional members username and nbf are intentionally omitted: this AS issues at+jwt tokens without nbf and does not persist a human-readable username (auth.provider's scope excludes profile storage — see project scope memory). Add them when a consumer needs them.

    interface IntrospectResponse {
        active: boolean;
        aud?: string | readonly string[];
        azp?: string;
        client_id?: string;
        cnf?: Confirmation;
        exp?: number;
        iat?: number;
        iss?: string;
        jti?: string;
        scope?: string;
        sub?: string;
        token_type?: "Bearer" | "DPoP";
    }
    Index

    Properties

    active: boolean
    aud?: string | readonly string[]
    azp?: string
    client_id?: string

    RFC 7662 §2.2 confirmation claim mirror. Present when the introspected token carries a cnf claim; absent otherwise.

    exp?: number
    iat?: number
    iss?: string
    jti?: string
    scope?: string
    sub?: string
    token_type?: "Bearer" | "DPoP"

    Wire-level token type. "DPoP" when the introspected token carries a cnf.jkt claim (per RFC 9449 §5 + RFC 7662 §2.2 consistency). "Bearer" otherwise — including mTLS-bound tokens, because RFC 8705 does not redefine the wire-level token type. Adding a new token_type variant (e.g. for a future sender-constrained scheme with its own IANA token-type registration) is a core semver-minor change, mirroring the Confirmation extension boundary in spec §4.3.