Attesto - OpenID-certified OAuth 2.1 / OpenID Connect for Elixir (Phoenix provider, client, and MCP auth)

Hi all - I’ve been building Attesto, a set of libraries that brings certified OAuth 2.1 and OpenID Connect to Elixir, whether you want to be an identity provider, talk to one, or put OAuth in front of an MCP server.

It’s OpenID Certified, including FAPI 2.0 (Security Profile and Message Signing), the bank-grade profile behind open banking. As far as I can tell from the OpenID Foundation’s directory, that makes it the first Elixir provider certified for FAPI 2.0. The certs also cover OpenID Connect Basic and Config, all three Logout profiles, Session Management, and FAPI-CIBA, and they run against the Foundation’s conformance suite rather than being self-asserted.

For Phoenix apps, attesto_phoenix is a drop-in authorization server: /authorize, /token, PAR, DPoP, mTLS, PKCE - backed by your own Ecto schemas. You keep your login and consent screens, it handles the protocol.

On the MCP side, the spec now has servers act as OAuth 2.1 resource servers, and attesto_mcp handles that boundary. It protects your /mcp endpoint, publishes the RFC 9728 metadata that lets Claude, ChatGPT, and other MCP clients discover how to authorize, verifies Bearer/DPoP/mTLS tokens locally, and enforces scopes before a request reaches your tools. It drops straight into Anubis, or any Plug/Phoenix MCP server.

If you’re on the client side, attesto_client covers the relying-party work: discovery, JWKS, ID-token and JARM verification, request objects, private_key_jwt.

All of it sits on a small conn-free core with no Phoenix or Ecto assumptions, so you can build on that directly if you’re on a different stack.

Everything’s on Hex with docs, and I’d welcome feedback, especially from anyone doing OAuth for MCP.

Hex: attesto · attesto_phoenix · attesto_client · attesto_mcp

11 Likes

Several updates since the initial announcement.

Most of this falls under OpenID for Verifiable Credentials (OID4VC), the protocols behind the EU Digital Identity Wallet, across all three specified roles:

  • Issuer (OID4VCI) attesto_phoenix mounts the issuance endpoints; after your own auth/consent you hand a wallet a credential as SD-JWT VC, ISO 18013-5 mdoc, or jwt_vc_json. For when you’re the one attesting something: a PID/eID provider, a university issuing diplomas, a bank issuing an account credential.
  • Verifier (OID4VP) the presentation side. A wallet presents a credential and you verify the issuer signature, holder binding, and only the claims you asked for (DCQL, selective disclosure). Anywhere you’d otherwise photograph an ID - KYC, age checks, entitlement - without the raw document.
  • Holder (the wallet itself) new in attesto_client: take a credential offer, prove the holder key, request and verify the credential, then present it back to a verifier.

Targets the High Assurance Interoperability Profile (HAIP) and runs green against the OpenID Foundation’s OID4VCI/OID4VP conformance suites. Those suites are still alpha so these are not new certifications yet.

A few things outside the wallet work:

  • attesto_client is now OpenID Certified as a Relying Party (Basic/Config/Dynamic) — the client side is certified now too, not just the provider.
  • Resource Indicators (RFC 8707) in the provider and core: an access token is audience-bound to one resource, so a token minted for API A can’t be replayed at B. Useful anywhere one deployment fronts several APIs.
  • attesto_mcp picked up that per-resource confinement plus multi-resource routing: host several OAuth-protected MCP servers behind one app, each with tokens scoped to it. (It’s the auth boundary in front of your MCP server; the transport/streaming stays with your server lib, e.g. anubis_mcp.)

There’s also been substantial hardening and correctness fixes across the releases. I recommend updating when convenient, but nothing is critical.

Latest versions are attesto 1.8.0, attesto_phoenix 2.7.0, attesto_client 2.3.0, attesto_mcp 1.0.5.

4 Likes