Skip to main content

OAuth Yetkilendirme Sunucusu (OAuth Authorization Server)

Sistem Analizi

Güvenlik, Kimlik ve Güven

Normal Davranış

Yetkilendirme onayı akışlarını (authorization grant flows) (PKCE ile Yetkilendirme Kodu Akışı veya İstemci Kimlik Bilgileri Akışı gibi) koordine eder. İstemci kimlik bilgilerini (client credentials) ve kullanıcı kimlik doğrulamasını (user authentication) doğruladıktan sonra, kapsamı belirlenmiş (scoped) izinler içeren kısa ömürlü erişim belirteçleri (access tokens) üretir, belirteçleri açık bir JWKS uç noktası üzerinden sunulan özel anahtarlarla (private keys) imzalar, uzun ömürlü yenileme belirteçleri (refresh tokens) verir ve belirteç iç gözlemi (introspection) ile iptal (revocation) API'leri sunar.

Çöküş Davranışı

Bir geliştirici, istemci kayıtlarında (client registrations) aşırı esnek joker karakter yönlendirme URI'leri (wildcard redirect URIs) (örn. https://*.example.com/callback) yapılandırır; bir saldırgan, yetkilendirme kodunu ele geçirmek (intercept) için bir alt alan adındaki (subdomain) açık yönlendirme (open redirect) güvenlik açığından yararlanır, bunu bir erişim belirteciyle (access token) değiştirir ve yukarı akış (upstream) API'leri üzerinden hassas kullanıcı verilerini sızdırır (exfiltrates).

İş Sonuçları

Bir OAuth Yetkilendirme Sunucusu (OAuth Authorization Server), API izinlerini yöneten erişim belirteçlerini (access tokens) verir. Buradaki bir arıza, tüm aşağı akış (downstream) mikro hizmetlerin ve üçüncü taraf entegrasyonlarının isteklerin kimliğini doğrulama yeteneğini ellerinden alır. Bu, tüm kullanıcı eylemlerinde, üçüncü taraf veri senkronizasyonunda ve ortak API entegrasyonlarında anında, kesin bir durma yaratır ve ürün ekosistemini tamamen devre dışı bırakır.

Görsel Tezahür

"Platform genelindeki her API çağrısının aniden HTTP 401 Unauthorized (Yetkisiz) veya HTTP 403 Forbidden (Yasaklı) döndürmesi ve loglarda bir 'Geçersiz Belirteç' (Invalid Token) hatası seli."

Satirical Behavior

"A cryptographically complex implementation of passing notes in class, designed to ensure nobody can log in if a certificate expires on a Sunday."

Bilinen İsimler

Authorization ServerToken Server

Teknik Terminoloji

Access TokenRefresh TokenScopesClient Credentials

Hata Göstergeleri

Invalid clientUnsupported grant typeInvalid scope

Sistem Mimarisi

Click or hover to interact

FAQ

Normalde nasıl davranır?

Yetkilendirme onayı akışlarını (authorization grant flows) (PKCE ile Yetkilendirme Kodu Akışı veya İstemci Kimlik Bilgileri Akışı gibi) koordine eder. İstemci kimlik bilgilerini (client credentials) ve kullanıcı kimlik doğrulamasını (user authentication) doğruladıktan sonra, kapsamı belirlenmiş (scoped) izinler içeren kısa ömürlü erişim belirteçleri (access tokens) üretir, belirteçleri açık bir JWKS uç noktası üzerinden sunulan özel anahtarlarla (private keys) imzalar, uzun ömürlü yenileme belirteçleri (refresh tokens) verir ve belirteç iç gözlemi (introspection) ile iptal (revocation) API'leri sunar.

Nasıl çöker?

Bir geliştirici, istemci kayıtlarında (client registrations) aşırı esnek joker karakter yönlendirme URI'leri (wildcard redirect URIs) (örn. https://*.example.com/callback) yapılandırır; bir saldırgan, yetkilendirme kodunu ele geçirmek (intercept) için bir alt alan adındaki (subdomain) açık yönlendirme (open redirect) güvenlik açığından yararlanır, bunu bir erişim belirteciyle (access token) değiştirir ve yukarı akış (upstream) API'leri üzerinden hassas kullanıcı verilerini sızdırır (exfiltrates).

İş sonuçları nelerdir?

Bir OAuth Yetkilendirme Sunucusu (OAuth Authorization Server), API izinlerini yöneten erişim belirteçlerini (access tokens) verir. Buradaki bir arıza, tüm aşağı akış (downstream) mikro hizmetlerin ve üçüncü taraf entegrasyonlarının isteklerin kimliğini doğrulama yeteneğini ellerinden alır. Bu, tüm kullanıcı eylemlerinde, üçüncü taraf veri senkronizasyonunda ve ortak API entegrasyonlarında anında, kesin bir durma yaratır ve ürün ekosistemini tamamen devre dışı bırakır.

Why is Proof Key for Code Exchange (PKCE) mandatory for single-page apps and mobile clients using OAuth 2.0?

Public clients (SPAs and native mobile apps) cannot securely store a static client secret. PKCE solves this by generating a dynamic, cryptographic code_verifier and hashed code_challenge per request, preventing malicious apps on the same device from intercepting the authorization code and exchanging it for an access token.

How should an OAuth Authorization Server handle token revocation to prevent stale access token usage across distributed microservices?

Because stateless JWT access tokens cannot be revoked before their expiration timestamp without distributed state lookups, servers must issue short-lived JWT access tokens (5-15 minutes), maintain a centralized Revocation/Blacklist cache (in Redis) for revoked tokens, and enforce refresh token rotation on every renewal.

Sistemi keşfet

Incidentpedia'da devam et→Olay Dizinini oku→Stack'leri incele→Konuları keşfet→Bölümleri izle→Ajanlar→

AI özeti

OAuth Server is a SECURITY_IDENTITY_AND_TRUST system in TinyCTO.tv. Coordinates authorization grant flows (such as Authorization Code Flow with PKCE or Client Credentials Flow). Upon verifying client credentials and user authentication, it generates short-lived access tokens containing scoped permissions, signs tokens with private keys exposed via a public JWKS endpoint, issues long-lived refresh tokens, and provides token introspection and revocation APIs.