entropy-auth 2026.7.31

Authentication and authorization for Entropy Softworks server and API projects
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

//! Authorization-server (identity-provider) side of the OAuth 2.0 /
//! `OpenID` Connect flow.
//!
//! The parent [`oauth`](crate::oauth) module is **client-side**: it builds
//! the requests a relying party sends to an authorization server. This
//! submodule is the mirror image — the **server-side** decision logic an
//! identity provider runs when those requests arrive. Both halves are
//! deliberately transport-free and storage-free: this module validates,
//! evaluates, and mints, while the caller owns HTTP and persistence.
//!
//! # Layout choice
//!
//! These types live under `oauth::server` rather than a sibling top-level
//! `idp` module so the client/server symmetry is visible in the path
//! (`oauth::AuthorizationRequest` builds what `oauth::server` validates) and
//! so they share the parent module's PKCE, state, and token-request types
//! without a cross-module dependency. This matches the crate's
//! one-concept-per-module / cohesive-grouping convention.
//!
//! # Contents
//!
//! * [`RegisteredClient`] / [`ClientType`] — the read-only client view the
//!   validators consume (RFC 6749 §2).
//! * [`validate_authorize_request`] — authorize-endpoint validation with the
//!   RFC 6749 §4.1.2.1 display-vs-redirect error split.
//! * [`evaluate_code_redemption`] — authorization-code redemption verdict
//!   (RFC 6749 §4.1.3, RFC 7636 §4.6).
//! * [`evaluate_refresh`] — refresh-token rotation + reuse-detection state
//!   machine (RFC 6749 §10.4, OAuth 2.1 §6.1).
//! * [`IntrospectionResponse`] — RFC 7662 introspection response shape +
//!   serializer.
//! * [`IdTokenBuilder`] — OIDC ID-token claims helper feeding
//!   [`JwtEncoder`](crate::jwt::JwtEncoder).
//!
//! # Security
//!
//! Comparisons of attacker-influenced secret-adjacent material — redirect
//! URIs, PKCE challenges, and the client-id binding in the token/refresh
//! paths — use
//! [`constant_time_eq`](crate::crypto::constant_time::constant_time_eq).
//! (The authorize endpoint's client lookup is an ordinary equality match on a
//! public identifier, not a secret compare.) No secret material appears in any
//! error `Display` output.

mod authorize;
mod client;
#[cfg(feature = "asym-jwt")]
mod client_assertion;
mod client_credentials;
mod code;
mod id_token;
mod introspection;
mod refresh;

pub use self::authorize::{
    AuthorizeError, AuthorizeErrorCode, AuthorizeRedirectError, AuthorizeRequest,
    DisplayErrorReason, ValidatedAuthorizeRequest, validate_authorize_request,
};
pub use self::client::{
    ClientType, RegisteredClient, RegisteredClientBuilder, RegisteredClientError,
};
#[cfg(feature = "asym-jwt")]
pub use self::client_assertion::{ClientAssertion, ClientAssertionDenied, verify_client_assertion};
pub use self::client_credentials::{
    ClientCredentialsDenied, ClientCredentialsRequest, ClientCredentialsVerdict,
    evaluate_client_credentials,
};
pub use self::code::{
    ClientAuthResult, CodeRedemptionDenied, CodeRedemptionVerdict, StoredAuthCode,
    TokenRequestPresented, evaluate_code_redemption,
};
pub use self::id_token::IdTokenBuilder;
pub use self::introspection::IntrospectionResponse;
pub use self::refresh::{
    RefreshDenied, RefreshOutcome, RefreshPresented, StoredRefreshToken, evaluate_refresh,
};