pas-external 0.14.1

Ppoppo Accounts System (PAS) external SDK — OAuth2 PKCE, JWT verification port, Axum middleware, session liveness
Documentation 
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
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140

//! γ port-and-adapter SDK boundary for OpenID Connect Relying Party
//! (RP) integration.
//!
//! Phase 10.11 — sibling of [`crate::token`]. Where `token::*` exposes
//! the [`BearerVerifier`](crate::BearerVerifier) port for RFC 9068
//! access-token verification (the resource-server side of OAuth), this
//! module exposes [`IdTokenVerifier`] for OIDC id_token verification
//! (the user-authentication side). The two are intentionally disjoint:
//! id_tokens authenticate the user *to the RP*, access_tokens authorize
//! the RP *to the resource server* (OIDC Core §1.2 / RFC 9068 §1).
//!
//! Phase 11.A — adds [`RelyingParty<S>`] composition root + the
//! [`StateStore`] port + `discovery` primitive. The verify-half
//! ([`IdTokenVerifier`] + [`PasIdTokenVerifier`]) stays as the
//! resource-side surface; [`RelyingParty<S>`] composes both halves
//! (start_authorization → callback completion) for the user-flow side.
//!
//! ── Module layout — mirrors [`crate::token`] for parallel structure ─────
//!
//! - [`port`] — [`IdTokenVerifier`], [`IdAssertion`], [`IdVerifyError`]
//!   (always compiled when `token` feature is on; depends on engine
//!   `ScopeSet` / `Nonce` types).
//! - [`verifier`] — [`PasIdTokenVerifier<S>`] production adapter (gated
//!   `well-known-fetch`; depends on the engine's id_token verify entry
//!   and a TTL-cached JWKS).
//! - [`memory`] — [`MemoryIdTokenVerifier<S>`] +
//!   [`InMemoryStateStore`] test-support adapters (gated
//!   `cfg(any(test, feature = "test-support"))`).
//! - [`state_store`] — [`StateStore`] port + value types ([`Config`],
//!   [`State`], [`RelativePath`], [`PendingAuthRequest`],
//!   [`AuthorizationRedirect`], [`CallbackParams`], [`Completion<S>`])
//!   (gated `feature = "oauth"` + `feature = "token"`; Phase 11.A).
//! - [`discovery`] — `fetch_discovery` primitive for OIDC
//!   well-known-openid-configuration documents (gated
//!   `feature = "well-known-fetch"`; Phase 11.A).
//! - [`relying_party`] — [`RelyingParty<S>`] composition root (gated
//!   `feature = "well-known-fetch"`; Phase 11.A skeleton, Phase 11.B
//!   impl).
//!
//! ── AuditSink — access-token verifier only ──────────────────────────────
//!
//! Verify-failure audit emission lives on the public access-token
//! [`PasJwtVerifier`](crate::JwtVerifier) surface (its `with_audit`
//! builder). The `pub(crate)` id_token `PasIdTokenVerifier` does not
//! emit audit events: it is reachable only through [`RelyingParty<S>`],
//! which wires no sink, so the emission path was removed rather than
//! left unreachable. The shared [`AuditSink`](crate::AuditSink) port and
//! the [`VerifyErrorKind`](crate::VerifyErrorKind) vocabulary (including
//! its `IdToken(_)` variant) remain available for the access-token
//! surface.
//!
//! ── Scope re-exports ────────────────────────────────────────────────────
//!
//! The engine's [`scopes`](ppoppo_token::id_token::scopes) markers are
//! re-exported here so consumers reach them via the SDK boundary:
//!
//! ```ignore
//! use pas_external::oidc::{IdTokenVerifier, Openid, Email, EmailProfile};
//! ```
//!
//! rather than depending on `ppoppo-token` directly. This preserves the
//! γ invariant: the engine type never crosses the SDK boundary except
//! through SDK-shaped re-exports.

#[cfg(feature = "token")]
pub mod port;

#[cfg(feature = "well-known-fetch")]
pub(crate) mod verifier;

#[cfg(all(feature = "token", feature = "oauth"))]
pub mod state_store;

/// Thin re-export of `ppoppo_sdk_core::discovery::*` — Phase A Slice 2
/// moved the primitive to sdk-core so any RP composition root (today
/// pas-external; tomorrow pas-plims / pcs-external) consumes the same
/// `fetch_discovery` + `Discovery` + `DiscoveryError` shapes.
#[cfg(feature = "well-known-fetch")]
pub mod discovery {
    pub use ::ppoppo_sdk_core::discovery::*;
}

#[cfg(feature = "well-known-fetch")]
pub mod relying_party;

#[cfg(feature = "well-known-fetch")]
pub mod refresh_outcome;

#[cfg(all(feature = "token", any(test, feature = "test-support")))]
pub mod memory;

// Phase A Slice 4 — perimeter `BearerAuthLayer` Layer kit moved to
// `ppoppo_sdk_core::bearer::*` so 1st-party services (chat-auth) can
// import direct (audit decision B). pas-external re-exports the kit at
// the crate root as `pas_external::bearer::*` for 3rd-party RCW/CTW
// consumers (audit decision D — 1-level role-named module, no nesting).
// No `oidc::axum::*` namespace remains — see crate root `bearer` module
// in this crate's `lib.rs`.

#[cfg(feature = "token")]
pub use port::{Address, IdAssertion, IdTokenVerifier, IdVerifyError, ScopePiiReader};

#[cfg(all(feature = "token", feature = "oauth"))]
pub use state_store::{
    AuthorizationRedirect, CallbackParams, Completion, Config, PendingAuthRequest, RelativePath,
    RelativePathError, State, StateStore, StateStoreError,
};

#[cfg(feature = "well-known-fetch")]
pub use discovery::{fetch_discovery, Discovery, DiscoveryError};

#[cfg(feature = "well-known-fetch")]
pub use relying_party::{
    CallbackError, EndSessionError, RefreshError, RelyingParty, RelyingPartyInitError,
    RequestedScope, StartError,
};

#[cfg(feature = "well-known-fetch")]
pub use refresh_outcome::RefreshOutcome;

#[cfg(all(feature = "token", any(test, feature = "test-support")))]
pub use memory::MemoryIdTokenVerifier;

#[cfg(all(
    feature = "token",
    feature = "oauth",
    any(test, feature = "test-support")
))]
pub use memory::InMemoryStateStore;

// Engine re-exports — consumers reach scope markers + Nonce via the SDK
// boundary rather than depending on `ppoppo-token` directly.
#[cfg(feature = "token")]
pub use ppoppo_token::id_token::{
    Nonce,
    scopes::{
        Email, EmailProfile, EmailProfilePhone, EmailProfilePhoneAddress, HasAddress, HasEmail,
        HasPhone, HasProfile, Openid, Profile, ScopeSet,
    },
};