Geliştirici dostu · Headless · Apache 2.0
OAuth 2.1 ve OpenID Connect, sizin yönetiminizde
İnsanlar, servisler ve yapay zekâ ajanları için standartları önceleyen bir yetkilendirme sunucusu; bir yan projeden ulusal kimlik dağıtımına kadar. Tasarımı gereği headless: giriş ekranlarınızı Interaction API üzerine kendiniz kurun (OpenAPI 3.1, tipli istemci) ya da referans sayfaları kullanın. Her yerde PKCE, RFC 8693 yetki devri, MCP yetkilendirme profili ve bir bayrağın arkasında hibrit ML-DSA-65 imzalama. PostgreSQL ve Redis ile Fastify üzerinde TypeScript.
# Compose 2 ile Docker 23+ ve OpenSSL gerekir
❯ git clone https://github.com/qauth-labs/qauth.git && cd qauth
❯ cp .env.docker.example .env
# JWT_PRIVATE_KEY, JWT_PUBLIC_KEY, KEK ve DB_PASSWORD değerlerini .env dosyasına ekleyin
❯ docker compose up -d
❯ curl http://localhost:3000/ready
Her değeri nasıl üreteceğinizi Docker kılavuzunda bulabilirsiniz.
Bugün sunulanlar
Özellikler
Tam listeyi ve her ayarın neyi açtığını durum sayfasında bulabilirsiniz. Varsayılan olarak kapalı olanlar: WALLET_FEDERATION_ENABLED, HYBRID_SIGNING_ENABLED, ID_JAG_ENABLED (kurum tarafından yönetilen yetkilendirme) ve DPOP_ENABLED (RFC 9449).
Ajanlar için tasarlanmış yetkilendirme
Ajan istemci türü, act claim içeren RFC 8693 on-behalf-of token değişimi, istemci başına üst sınırı belirlenen ReadOnly / Admin / Exec kapsam modları, tehlikeli işlemlerden önce ek doğrulama (step-up) ve ajan başına denetim kaydı. Yalnızca MCP için değil, herhangi bir API'yi çağıran her ajan için.
MCP yetkilendirme profili
2026-07-28 revizyonu: RFC 9728 korumalı kaynak meta verisi, yedek yöntem olarak RFC 7591 ile Client ID Metadata Documents, audience bağlama ve ek doğrulama istekleri. Kaynak sunucu tarafını @qauth-labs/resource-guard üstlenir.
OAuth 2.1 ve OpenID Connect çekirdeği
Zorunlu PKCE ile authorization code, client_credentials, rotasyonlu refresh token'lar, discovery, JWKS, ID token'lar, userinfo, introspection, revocation, RFC 8707 kaynak göstergeleri ve RP tarafından başlatılan ile back-channel oturum kapatma.
Kuantum sonrası hibrit imzalama
Varsayılan olarak Ed25519. Tek bir bayrak, hibrit ML-DSA-65 + Ed25519 imzaları ve karma bir AKP+OKP JWKS ekler; kuantum sonrası bileşen introspection üzerinden sunulur.
Kendi sunucunuzda, çok kiracılı
Her biri kendi issuer değerine ve host adlarına sahip realm'ler, istemciler ve API anahtarları için bir geliştirici portalı ve şifrelenmiş imzalama anahtarları. Yapılandırılmış loglar, Prometheus metrikleri ve OpenTelemetry olayları sizin izleme sisteminize gider; bize hiçbir şey gönderilmez.
Federasyon
Bugün, bir realm'in upstream OpenID Connect sağlayıcıları üzerinden giriş. SD-JWT VC ile OID4VP 1.0 üzerinden AB Dijital Kimlik Cüzdanı ile giriş bir bayrağın arkasında sunuluyor; sahte (mock) bir cüzdana karşı test edildi, gerçek cüzdanlarla test henüz yapılmadı.
Çekirdek protokol
Tek yetkilendirme sunucusu, her tür istemci için
Hiçbir ajan işin içine girmeden önce de QAuth bir OAuth 2.1 ve OpenID Connect sunucusudur: kullanıcılarınız için zorunlu PKCE (S256) ile authorization code, servisleriniz için client_credentials, tekrar kullanıldığında tüm ailesini iptal eden rotasyonlu refresh token'lar, discovery, JWKS, userinfo, introspection ve revocation. Implicit flow yok, tescilli bir SDK da gerekmez. Ajan yetki devri ve MCP desteği de aynı çekirdeğin üzerinde çalışır.
Ajan yetkilendirmesi
Ajanlar iş yapar, hesabını yetkilendirme sunucunuz verir.
Ajan yetkilendirmesi, birkaç adım eklenmiş kullanıcı yetkilendirmesi değildir. Bir token'ın “X ajanı, Y kullanıcısı adına çalışıyor” diyebilmesi gerekir; bu yüzden RFC 8693 token değişimi, act claim içeren devredilmiş bir token üretir. Ajanlar bir client ID için talep de açamaz; bu yüzden Client ID Metadata Documents ile, yedek olarak da RFC 7591 ile makine hızında kaydolurlar. Geliştirme ortamındaki bir ajan asla canlı ortama ulaşmaz: ortam, politikanın bir boyutudur. Bunların hepsi bugün sunuluyor ve bir MCP sunucusunun önünde de sade bir REST API'nin önünde de aynı şekilde çalışır.
Entegrasyon
Ayağınıza dolanmayanyetkilendirme
Kaynak sunucularınızı, ister MCP ister sade REST olsun, standartlara dayalı OAuth 2.1 ile koruyun: RFC 9728 keşfi, meta veri belgesiyle istemci kaydı ve PKCE. SDK isteğe bağlıdır; herhangi bir OAuth kütüphanesiyle çalışır.
QAuth'u çalıştırın
Docker Compose imajları derler, migration'ları çalıştırır ve yetkilendirme sunucusunu PostgreSQL 18 ve Redis 7 ile başlatır. Komutlar yukarıdaki hızlı başlangıçta.
Bir kaynak sunucusunu koruyun
Bir MCP sunucusunda @qauth-labs/resource-guard eklentisini kaydedin ya da sade bir REST API'de bearer token'ları JWKS ile kendiniz doğrulayın. Her iki durumda da token'lar audience'a bağlıdır.
İstemcilerin giriş yapmasını sağlayın
Claude Code gibi MCP istemcileri yetkilendirme sunucunuzu keşfeder, bir Client ID Metadata Document ile kaydolur ve PKCE ile authorization_code akışını çalıştırır. Servisler bunun yerine client_credentials kullanır.
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
Kuantum sonrası
Hibrit ML-DSA-65 imzalama bugün hazır
İmzalama, algoritmadan bağımsız arayüzlerin arkasında çalışır. SIGNING_ALGORITHM_MODE=ed25519+ml-dsa-65 ve HYBRID_SIGNING_ENABLED=true ayarlandığında QAuth, Ed25519'un yanında ML-DSA-65 ile de imzalar, karma bir JWKS yayımlar ve kuantum sonrası bileşeni introspection üzerinden sunar. Yalnızca Ed25519 bilen doğrulayıcılar çalışmaya devam eder.