auth-meta
Facebook Login. Its own crate, because Meta is not an OpenID Connect provider however much it looks like one.
As a git dependency
cargo add cratefield-auth-meta --git https://github.com/Cratefield/harnessIn the repository, not on crates.io yet.
What it is
auth-meta.
The authorization code flow with PKCE, sealed into a signed cookie at /start and spent at the callback, then the linking rules and a session — the same shape auth-oidc uses for Google and Apple.
It is a separate crate because Meta is not an OpenID Connect provider. No discovery document, no ID token, no nonce: what comes back from the authorization code is a plain OAuth 2.0 access token, and who the person is comes from a Graph call made with it. Folding that into the OIDC flow would mean a provider descriptor with a hole in the middle of it, and every reader of that flow would have to know which providers fall through the hole. ADR 0204 records it.
Ports
Database · Clock · IdGen · Signer · HttpClient
Routes
/v1/auth-meta
- GET
/v1/auth-meta/start ?return_to=/path - GET
/v1/auth-meta/callback ?code&state - POST
/v1/auth-meta/data-deletion - GET
/v1/auth-meta/deletion-status ?code=…
Rate limited
Every route here is reachable by anyone, and it is /callback that makes this service talk to Meta — the token exchange and the profile call both happen there. Limited wherever a limiter exists.
History
Changelog.
Not released on its own: it is taken from the repository as a git dependency, and has no CHANGELOG.md yet.
A Meta sign-in never links itself to an existing account, and that is the module's central decision rather than a gap. auth-core auto-links on a verified email, so a verified address is a key — and Meta does not assert verification in a form this service can rely on. Believing it would let anyone who can get an address onto a Facebook account walk into the matching account here, so this module reports the address as unverified, always.