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
/*!
The foundational traits and types for the huskarl `OAuth2` ecosystem.
Most applications depend on the higher-level `huskarl` crate (grants, token
cache, authorizer) rather than this crate directly. `huskarl-core` is the shared
base they build on — the utilities below are also useful on their own, whether
you are writing OAuth tooling or implementing a backend for the rest of the
ecosystem.
## The huskarl ecosystem
This crate is one of three that fit together. Each carries its own how-to guides
and explanation in a `_docs` module:
- [`huskarl`](https://docs.rs/huskarl) — `OAuth2` **clients**: grants, token
caching, and the request authorizer.
- [`huskarl-resource-server`](https://docs.rs/huskarl-resource-server) —
**resource servers**: access-token validation and request authorization.
- **`huskarl-core`** (this crate) — the shared **foundation** the other two
build on.
## What's here
- **JOSE primitives** — [`jwt`] builds, signs, and validates JWTs; [`jwk`]
parses and produces JWK/JWKS wire types; [`crypto`] holds the signing,
verification, and encryption traits plus a set of composable wrappers
(multi-key, refreshable, retrying).
- **Secret handling** — [`secrets`] retrieves credentials from environment
variables, files, or your own provider, behind redacted wrappers that keep
them out of logs, with optional decoding and caching.
- **Client authentication** — [`client_auth`] carries the ways a client
authenticates to an authorization server (client secret, private-key JWT, or
none).
- **`DPoP`** — [`dpop`] provides proof-of-possession binding for the
authorization-server and resource-server flows.
- **HTTP** — [`http`] defines the [`HttpClient`](http::HttpClient) seam that
decouples the ecosystem from any specific HTTP implementation.
- **Authorization-server metadata** — [`server_metadata`] models RFC 8414 /
OIDC discovery documents.
- **Wire encoding** — [`oauth_form`] serializes OAuth messages as
`application/x-www-form-urlencoded`, including structured RFC 9396 values.
- **Errors** — the flows return the one concrete [`Error`]/[`ErrorKind`],
which embeds cleanly in your own error type. A few subsystems return their
own typed errors where the variants *are* the API — JWT validation
([`JwtValidationError`](jwt::validator::JwtValidationError)), low-level
verification ([`crypto::verifier`]), and wire encoding
([`oauth_form::Error`]) — design one `From` arm for [`Error`] plus arms for
the subsystem errors you call directly.
## Guides and explanation
The API items here are the **reference** documentation. For task-oriented how-to
guides — [building](_docs::guide::signing_a_jwt) and
[validating](_docs::guide::validating_a_jwt) JWTs,
[providing secrets](_docs::guide::providing_secrets), and
[implementing a backend](_docs::guide::implementing_a_backend) — and design
explanation — [the error model](_docs::explanation::error_handling),
[handling untrusted keys](_docs::explanation::untrusted_keys), and
[composing crypto strategies](_docs::explanation::crypto_strategies) — see the
[`_docs`] module.
*/
// The dyn-capable strategy traits are shared between native and wasm32 behind
// `Arc<dyn Trait>`. On wasm32 (single-threaded) the implementations are
// intentionally not `Send`/`Sync` (see `platform::MaybeSend`), which trips this
// lint even though the `Arc` never crosses a thread boundary there.
pub use AuthorizationDetail;
pub use EndpointUrl;
pub use ;