Liigu põhisisu juurde
QAuth Labs
Lisage GitHubis tärn

Arendajasõbralik · Headless · Apache 2.0

OAuth 2.1 ja OpenID Connect, teie enda käes

Standarditest lähtuv autoriseerimisserver inimestele, teenustele ja AI-agentidele, kõrvalprojektist kuni riikliku e-identiteedi juurutuseni. Olemuselt headless: ehitage oma sisselogimisekraanid Interaction API peale (OpenAPI 3.1, tüübitud klient) või kasutage näidislehti. PKCE kõikjal, RFC 8693 delegeerimine, MCP-autoriseerimisprofiil ja lipu taga hübriidne ML-DSA-65 allkirjastamine. TypeScript Fastify peal, PostgreSQLi ja Redisega.

# Nõuded: Docker 23+ koos Compose 2-ga ja OpenSSL

❯ git clone https://github.com/qauth-labs/qauth.git && cd qauth

❯ cp .env.docker.example .env

# lisage .env-faili JWT_PRIVATE_KEY, JWT_PUBLIC_KEY, KEK ja DB_PASSWORD

❯ docker compose up -d

❯ curl http://localhost:3000/ready

Kuidas iga väärtus genereerida: Dockeri juhend.

OAuth 2.1
OpenID Connect 1.0
PKCE
RFC 8693
RFC 8707
RFC 9728
RFC 9449 DPoP
MCP 2026-07-28

Mis on täna olemas

Võimalused

Täielik loetelu ja see, mida iga lüliti sisse lülitab, on olekulehel. Vaikimisi välja lülitatud: WALLET_FEDERATION_ENABLED, HYBRID_SIGNING_ENABLED, ID_JAG_ENABLED (ettevõtte hallatav autoriseerimine) ja DPOP_ENABLED (RFC 9449).

Agentidele loodud autoriseerimine

Agendi klienditüüp, RFC 8693 on-behalf-of tokenivahetus act-väitega, kliendipõhise ülempiiriga ReadOnly / Admin / Exec scope-režiimid, step-up enne ohtlikke toiminguid ja auditijälg iga agendi kohta. Igale agendile, mis kutsub mis tahes API-t, mitte ainult MCP jaoks.

RFC 8693 · Step-up · Audit

MCP-autoriseerimisprofiil

Redaktsioon 2026-07-28: RFC 9728 kaitstud ressursi metaandmed, Client ID Metadata Documents koos RFC 7591-ga varulahendusena, audience-sidumine ja step-up-väljakutsed. Ressursiserveri poolt haldab @qauth-labs/resource-guard.

RFC 9728 · CIMD · resource-guard

OAuth 2.1 ja OpenID Connecti tuum

Authorization code kohustusliku PKCE-ga, client_credentials, roteeruvad refresh-tokenid, discovery, JWKS, ID-tokenid, userinfo, introspection, revocation, RFC 8707 ressursiindikaatorid ning RP algatatud ja back-channel väljalogimine.

OAuth 2.1 · OIDC 1.0

Kvantjärgne hübriidallkirjastamine

Vaikimisi Ed25519. Üks lipp lisab hübriidsed ML-DSA-65 + Ed25519 allkirjad ja segatud AKP+OKP JWKS-i, kusjuures kvantjärgset komponenti serveeritakse introspectioni kaudu.

ML-DSA-65 · FIPS 204 · Opt-in

Oma serverites, mitme rentnikuga

Realmid oma issueri ja hostidega, arendajaportaal klientide ja API-võtmete jaoks ning krüpteeritud allkirjavõtmed. Struktureeritud logid, Prometheuse mõõdikud ja OpenTelemetry sündmused lähevad teie seiresse; meile ei saadeta midagi.

Docker · Realms · Apache 2.0

Föderatsioon

Täna sisselogimine realmi upstream OpenID Connecti pakkujate kaudu. Sisselogimine ELi digiidentiteedikukruga üle OID4VP 1.0 ja SD-JWT VC tuleb kaasa lipu taga; seda on testitud näidiskukruga ja testimine päris kukrutega on veel tegemata.

Upstream OIDC · OID4VP 1.0 · Opt-in

Grant-tüübid kõrvuti

Inimesedauthorization_code + PKCESeanss + refresh-token
Teenusedclient_credentialsPiiratud ulatusega juurdepääsutoken
Iga klient/.well-known/openid-configurationRegistreerimine + JWKS-i avastamine

Sama server väljastab tokeneid sisselogimistele, teenusekutsetele ja delegeeritud agentidele: üks identiteedituum, mitte kolm kokku poltitud süsteemi.

Põhiprotokoll

Üks autoriseerimisserver, igat tüüpi kliendile

Enne kui agent midagi delegeerib, on QAuth OAuth 2.1 ja OpenID Connecti server: teie kasutajatele authorization code kohustusliku PKCE-ga (S256), teenustele client_credentials, roteeruvad refresh-tokenid, mis korduskasutuse korral tühistavad kogu oma perekonna, discovery, JWKS, userinfo, introspection ja revocation. Implicit flow puudub ja tootjaspetsiifilist SDK-d pole vaja. Agentide delegeerimine ja MCP tugi toetuvad samale tuumale.

PKCE

Kohustuslik igas authorization code voos

CIMD

Client ID Metadata Documents; varulahendusena RFC 7591

Väljalogimine

RP algatatud ja back-channel väljalogimine

OIDC

Standardne identiteedikiht, ilma tootjaspetsiifiliste väideteta

Delegeerimisvoog

DelegeerimineKasutajaToken Exchange (RFC 8693)JWT { sub: user, act: agent, aud: resource }
MõjualaReadOnlyAdminExec
Step-upExec + ohtlik toimingUus kinnitus inimeselt

Audience'iga seotud tokenid hoiavad agenti selle ühe ressursi piires, mille jaoks talle õigused delegeeriti; midagi muud pole kättesaadav.

Agentide autoriseerimine

Agendid tegutsevad. Teie autoriseerimisserver vastutab.

Agentide autoriseerimine ei ole kasutaja autoriseerimine paari lisasammuga. Token peab ütlema „agent X tegutseb kasutaja Y nimel“, seega väljastab RFC 8693 tokenivahetus delegeeritud tokeni act-väitega. Agendid ei saa ka client ID saamiseks taotlust esitada, seega registreeruvad nad masina kiirusel mehhanismi Client ID Metadata Documents kaudu, varulahendusena RFC 7591. Arenduskeskkonna agent ei jõua kunagi tootmisse: keskkond on poliitika üks mõõde. Kõik see on täna olemas ja töötab ühtmoodi nii MCP-serveri kui ka tavalise REST API ees.

RFC 8693

On-behalf-of tokenivahetus

3 režiimi

ReadOnly / Admin / Exec, kliendipõhise ülempiiriga

Step-up

Inimkinnitus enne ohtlikke toiminguid

Audit

Iga agendi auditijälg, iga delegeeritud toimingu kohta

Integreerimine

Autoriseerimine, misei jää teile jalgu

Kaitske oma ressursiservereid, olgu MCP või tavaline REST, standardipõhise OAuth 2.1-ga: RFC 9728 avastamine, kliendi registreerimine metaandmedokumendiga ja PKCE. SDK on valikuline; sobib iga OAuthi teek.

1

Käivitage QAuth

Docker Compose ehitab tõmmised, käivitab migratsioonid ja käivitab autoriseerimisserveri koos PostgreSQL 18 ja Redis 7-ga. Käsud leiate ülalolevast kiirstardist.

2

Kaitske ressursiserverit

Registreerige MCP-serveris @qauth-labs/resource-guard või kontrollige tavalises REST API-s bearer-tokeneid ise JWKS-i vastu. Mõlemal juhul on tokenid audience'iga seotud.

3

Laske klientidel sisse logida

MCP-kliendid, näiteks Claude Code, avastavad teie autoriseerimisserveri, registreeruvad Client ID Metadata Documenti abil ja käivitavad authorization_code voo PKCE-ga. Teenused kasutavad selle asemel client_credentials voogu.

import Fastify from 'fastify'

import { resourceGuardPlugin } from '@qauth-labs/resource-guard/fastify'


const app = Fastify()


// Protect your MCP resource server: audience-bound tokens only

await app.register(resourceGuardPlugin, {

  resource: 'https://mcp.yourapp.com',

  authorizationServer: 'https://auth.yourapp.com',

  requiredScopes: ['mcp:read'],

})


app.get('/mcp', { preHandler: app.requireBearer }, async (request) => {

  // request.tokenClaims: verified signature, issuer, audience, scope

  return { tools: listTools() }

})


// No token → 401 Unauthorized

// WWW-Authenticate: Bearer resource_metadata=

// "https://mcp.yourapp.com/.well-known/oauth-protected-resource"


// The MCP client (e.g. Claude Code) discovers your auth server from

// that document, registers via CIMD or RFC 7591, then runs

// authorization_code + PKCE for an audience-bound access token.


// Authorization: Bearer <token> → resource-guard verifies it → 200 OK

# Plain OAuth 2.1: no MCP, no agent, just your service

❯ curl -X POST https://auth.yourapp.com/oauth/token -d grant_type=client_credentials -d scope=documents:read

Hübriidallkirjastamise voog

VaikimisiEd25519JWT (64 B sig)Vaikimisi sees
SisselülitatavEd25519ML-DSA-65Hybrid JWTVälja antud
HiljemML-DSA-65PQC-only JWTHindamine 2028+

Bearer-token jääb tavaliseks Ed25519 JWS-iks. 3309-baidine ML-DSA-65 allkiri liigub vaikimisi RFC 7662 introspectioni kaudu, nii et päise- ega küpsisepiiranguid ei ületata. NIST IR 8547 tunnistab EdDSA, ECDSA ja RSA allkirjad pärast 2030. aastat aegunuks. „Koguda nüüd, dekrüpteerida hiljem“ ründab võtmevahetust, mitte allkirju: lõpetage TLS QAuthi ees X25519MLKEM768-ga.

Kvantjärgne

Hübriidne ML-DSA-65 allkirjastamine on täna olemas

Allkirjastamine asub algoritmist sõltumatute liideste taga. Seadke SIGNING_ALGORITHM_MODE=ed25519+ml-dsa-65 ja HYBRID_SIGNING_ENABLED=true ning QAuth allkirjastab Ed25519 kõrval ka ML-DSA-65-ga, avaldab segatud JWKS-i ja serveerib kvantjärgset komponenti introspectioni kaudu. Verifitseerijad, mis tunnevad ainult Ed25519, töötavad edasi.

Tase 3

ML-DSA-65 NIST-i turvakategooria

FIPS 204

ML-DSA standard, avaldatud 2024

Sisselülitatav

HYBRID_SIGNING_ENABLED, vaikimisi välja lülitatud

AKP+OKP

Segatud JWKS hübriidverifitseerijatele