Crate ferrohealth_smart 

The shared SMART App Launch 2.x and OAuth 2.0 resource-server crate of the FerroHEALTH products.

This crate is a library, never an authorization server: it issues no token and holds no key that signs one. Each deployment points it at its own standards-compliant authorization server, and the crate does four things every product needs:

• resource: the resource-server role. The issuer’s metadata is read at the RFC 8414 §3 location, with OpenID Connect Discovery 1.0 §4 as the fallback (metadata), its key set is read and read again on a rotation, and every JWT access token is validated under RFC 9068 (the signature with an asymmetric algorithm only, iss, aud, exp and nbf within a clock skew). A refused token is one generic 401 that names no claim (refusal).
• scope: the SMART App Launch 2.x scopes, patient/, user/ and system/ with the cruds permissions, and the patient compartment the token’s launch context names; a missing permission is a 403 that names no scope. Behind the openehr feature, openehr enforces the SMART on openEHR grammar beside it, parsed by openehr::smart_scopes: the template-, composition- and aql- families with their patterns, and the ehrId of the launch context. The product’s route table declares which grammar each route is checked against.
• basic and client: machine-to-machine authentication in exactly two modes, HTTP Basic (RFC 7617, verified against Argon2id hashes and sent outgoing) and the OAuth 2.0 client credentials grant (RFC 6749 §4.4, a token client with a cache and one renewal on a 401, authenticating with a secret or a private_key_jwt assertion). A static bearer token or an API key is not a mode.
• kind and profile: who stands behind a token. Each issuer declares its kind and a profile, a preset of what its tokens look like with any key set over it, and every valid token is classified as a patient, a system, a delegated person, a representative, a person or a guest, or refused naming the step it matched none of.
• party: the party a person’s login belongs to, looked up on every request through a source the product supplies, with one typed outcome. Where a token references its groups in place of carrying them, the idp adapter its issuer’s profile names reads them, each adapter behind its own feature.
• assurance: the assurance level of the authentication behind a token, with the RFC 9470 step-up refusal below a minimum.
• sender: sender-constrained tokens, bound by a DPoP proof (RFC 9449) or by the client certificate of a mutual-TLS connection (RFC 8705 §3), checked per issuer, with the proof replay store the product supplies.
• roles: the roles a caller holds, read from the claims RFC 9068 §2.2.3.1 names or granted to a Basic user, which a route requirement checks beside its scopes.
• audit: one audit line per request, which carries the principal, the client, the scheme, the issuer, the method, the route, what was addressed, the interaction, the status and the duration, and never the token or any content.

config holds the [auth] and [<lane>.credentials] sections every product embeds. The axum feature adds guard, the tower::Layer that runs the credential check, the scope check and the audit line in front of every route, and extract, the extractor of the caller the layer admitted. The core stays framework-neutral. The HTTP fetchers (the issuer’s metadata, the key set over its jwks_uri, and the client credentials token client) sit behind the default fetch feature; without it the crate links no HTTP client and reads a key set from a file. The oidc feature adds oidc, the OpenID Connect relying-party client an operator console signs its operator in with.

The openehr-scopes feature builds openehr::smart_scopes, the SMART on openEHR scope grammar, which depends on nothing. For the browser (wasm32-unknown-unknown) the grammar is the whole crate: the resource server is left out with its dependencies, so a browser client parses scopes with the parser the resource server enforces them with.

Modules

assurance

The assurance level of the authentication behind a bearer token.

audit

The one audit line of a request.

basic

HTTP Basic authentication (RFC 7617): a credential verified against a store of Argon2id hashes, and a credential sent to an upstream.

client

The credential a product obtains for itself with the OAuth 2.0 client credentials grant (RFC 6749 §4.4), cached and renewed before it expires.

config

The configuration sections every product embeds: [auth] for the surface it guards, and [<lane>.credentials] for each upstream it calls.

extract

The axum side of the guard: the extractor of the Access the layer admitted, and the renderer of a refusal that answers the status and the challenge with an empty body.

federation

The attributes a federation issuer asserts about another party’s professional or organisation, and the bounds they are held to.

guard

The tower layer in front of every route of an axum router: the credential check, the type-level scope check and the audit line.

idp

The vendor adapters: code for what an issuer’s profile cannot express as data, each behind its own Cargo feature and reached by the core only through IdpAdapter.

kind

Who stands behind a credential: the kind of issuer a token comes from and the CallerKind the token’s claims make its caller.

metadata

The authorization server metadata (RFC 8414 §2) and how it is found.

oidc

The OpenID Connect relying-party client an operator console signs in with.

openehr

The SMART on openEHR scope grammar and its grant check.

party

The party a person’s login belongs to: one lookup through a source the product supplies, with one match rule, one duplicate rule and one stable-claim rule, and one typed Outcome.

profile

The issuer profile: what one authorization server’s tokens look like and which of their claims say who stands behind them.

refusal

Why a request is refused at the gate, and the status and challenge it is answered with.

resource

The resource-server role: who calls, and what the caller’s access token permits.

roles

The roles a caller holds, read from its token’s claims.

scope

The SMART App Launch 2.x clinical scopes an access token grants.

sender

Sender-constrained access tokens: a token bound to a key its client proves with a DPoP proof (RFC 9449), or to the client certificate of the mutual-TLS connection (RFC 8705 §3).