Struct OauthRuntime 

pub struct OauthRuntime {
    pub codec: Codec,
    pub client: ClientConfig,
    pub client_id: String,
    pub client_key: Option<SigningKey>,
    pub auth_method: AuthMethod,
    pub locks: RefreshLocks,
    pub plc_directory: String,
    pub resolver: TokioResolver,
}

Everything the Rust OAuth client needs that outlives a request.

Fields

codec: Codec

At-rest encryption for sessions and the signing key.

client: ClientConfig

The validated client identity.

client_id: String

client_id, precomputed — it is derived, and recomputing it per request invites a divergence between what we send and what we publish.

client_key: Option<SigningKey>

The ES256 client key. None for the dev client, which is a public client and publishes no JWKS — and for a confidential client whose backend is not selected and which has no key file yet, since creating one it will never use is key material at rest for nothing.

auth_method: AuthMethod

How this client authenticates to the authorization server.

locks: RefreshLocks

Per-subject refresh serialization. One map process-wide, or the locking does nothing.

plc_directory: String

The PLC directory for did:plc resolution.

resolver: TokioResolver

The system DNS resolver, for handle → DID.

Implementations

impl OauthRuntime

pub fn new(cfg: &Config) -> Result<Self>

Build the runtime from configuration.

Dev is inferred from the public URL, exactly as the sidecar infers it, so the two agree on which client identity they present. A localhost public URL means atproto’s localhost development client: a public client with no JWKS.

The signing key is loaded (or created) only for a confidential client that is actually going to use it — i.e. when the Rust backend is the selected one. Two reasons, and the second is the one that bit:

• a dev client is public, so a key there is never used and never published, and later reads as “the key exists, so it must be in play”;
• the runtime is built on EVERY start so configuration errors surface early, including when the sidecar is serving. Creating the key as part of that validation meant a sidecar deployment wrote an ES256 private key it would never use — key material at rest, for nothing. In tests it also meant any AppState built with a production-like public_url dropped a private key into the working directory.