Microsoft 365 oturum açmaya çalışırken "AADSTS50058", "AADSTS70008" veya "AADSTS530003" gibi kod görürseniz bu Azure AD (Entra ID) kimlik doğrulama hatasıdır. Bu rehberde admin/IT/geliştirici tarafından en sık karşılaşılan 14 AADSTS hata kodunun sebebi + Türkçe açıklaması + çözüm adımları yer alıyor. AADSTS hatalarının çoğu MFA, Conditional Access, uygulama consent'i veya cihaz uyumluluğuyla ilgilidir — son kullanıcıdan değil, çoğu zaman tenant politikasından kaynaklanır.

AADSTS nedir? Azure AD Security Token Service'in (STS) ürettiği hata kodlarıdır. Microsoft 365, Azure, Power Platform, Dynamics 365 oturum açma akışlarında karşınıza çıkar. URL'ye yansır (?error=...&error_description=AADSTS50058) veya kullanıcıya "Sorun Oluştu" ekranında gösterilir.

Interaktif Arama
AADSTS Hata Kodu Lookup Tool →

Kodu yaz, anında Türkçe açıklama + çözüm gör (20+ kod kapsamlı)

Ücretsiz PDF
AADSTS Cheatsheet İndir →

Tek sayfa hızlı referans, masa başında elinizin altında dursun

Hızlı Bakış — AADSTS Hata Kodu Tablosu

KodAnlamıÇözen Rol
AADSTS50058Oturum bilgisi eksik (silent sign-in başarısız)Kullanıcı
AADSTS50053Hesap kilitlendi (Smart Lockout)Admin
AADSTS50055Parola süresi dolduKullanıcı
AADSTS50057Hesap devre dışıAdmin
AADSTS50074Strong auth gerekli (MFA prompt)Kullanıcı
AADSTS50076MFA challenge zorunlu (Conditional Access)Kullanıcı
AADSTS50079MFA enrollment gerekliKullanıcı
AADSTS65001Uygulama consent verilmediAdmin / Kullanıcı
AADSTS70008Authorization code süresi dolduGeliştirici
AADSTS90094Admin onayı gerekli (admin consent)Admin
AADSTS500011Resource principal bulunamadıAdmin / Geliştirici
AADSTS530003Cihaz uyumlu değil (Intune compliance)Admin
AADSTS530005Domain joined veya compliant cihaz şartAdmin
AADSTS900561İstek HTTP yöntemi yanlışGeliştirici

AADSTS50058 — "Oturum Bilgisi Eksik"

Anlamı: Tarayıcı silent (sessiz) sign-in denedi ama Azure AD'de geçerli oturum bilgisi bulamadı. Sürekli redirect döngüsü oluşabilir. Genelde son kullanıcı tarafında çözülür.

Çözüm Adımları

  1. Tarayıcıyı InPrivate/Incognito modda açın ve sorunlu uygulamaya tekrar girin. Eski cache/cookie kaldırılır.
  2. Sorun devam ediyorsa: Tarayıcı → Ayarlar → Çerezleri Temizle → login.microsoftonline.com + login.live.com alanlarını sil → tekrar dene.
  3. Birden fazla Microsoft hesabıyla giriş yaptıysanız (kişisel + iş hesabı aynı anda) tarayıcı yanlış hesabı seçmiş olabilir. portal.office.com/account/logout ile tüm hesaplardan çıkın.
  4. SSO altyapısı varsa (AD FS, Azure AD Connect): Identity Provider tarafında session token süresi dolmuş olabilir — admin'in Federation Service'i kontrol etmesi gerekir.

AADSTS50053 — "Hesap Kilitlendi"

Anlamı: Azure AD Smart Lockout devreye girdi — kullanıcı 10 (varsayılan) yanlış parola girdi veya bot saldırısı tespit edildi. Hesap 60 saniye - 15 dakika kilitlenir (artan ceza).

  1. Sabırla bekleyin — 60 saniye sonra ilk deneme, sonra 5 dk, sonra 15 dk artar.
  2. Admin müdahale ile kilit kaldırma: Microsoft Entra admin center → Users → kullanıcı → "Authentication methods" → "Require re-register MFA" veya "Reset password".
  3. Smart Lockout eşiği değiştirme (admin): Entra → Security → Authentication methods → Password protection → "Lockout threshold" (varsayılan 10) ve "Lockout duration" (60sn).
  4. Brute force saldırısı şüphesi varsa: Entra → Security → Identity Protection → "Risky users" panelinde tehdit skorunu kontrol edin. Yüksek riskli ise Conditional Access "Block Sign-in" politikası uygulayın.

AADSTS50055 — "Parola Süresi Doldu"

Anlamı: Kullanıcının parola yaş politikası gereği değişme süresi geldi. Varsayılan 90 gün (eski tenant'lar) — Microsoft 2019'dan beri "passwords never expire" öneriyor.

  1. Kullanıcı passwordreset.microsoftonline.com üzerinden self-service parola sıfırlama yapabilir (SSPR aktifse).
  2. Admin yeni parola atayabilir: Entra → Users → kullanıcı → "Reset password".
  3. Parola yaş politikasını kaldırma (önerilen, NIST 800-63B): Microsoft 365 admin center → Settings → Org settings → Security & privacy → Password expiration policy → "Set passwords to never expire" işaretli olmalı. Conditional Access + MFA'lı tenant'larda rotasyon güvenlik artırmaz.

AADSTS50074 / 50076 — "MFA Gerekli"

Anlamı: Conditional Access politikası bu oturum için MFA challenge gerektiriyor (50074) veya 50076: Authenticator app onayı / SMS / arama tamamlanmadan giriş engellendi.

  1. Kullanıcı Microsoft Authenticator notify'ı onaylasın veya SMS kodu girsin.
  2. Authenticator çalışmıyorsa: "Use a different verification method" → SMS / phone call / backup code dene.
  3. Cihaz kayboldu/değişti ise admin müdahale ile MFA yöntemini sıfırla: Entra → Users → kullanıcı → "Authentication methods" → "Require re-register MFA".
  4. Belirli kaynaklar için MFA bypass: Conditional Access → mevcut politikayı kontrol et → "Trusted locations" tanımla → ofis IP'sinden MFA istenmez.

AADSTS50079 — "MFA Enrollment Gerekli"

Anlamı: Bu kullanıcı henüz MFA için yöntem (Authenticator/SMS/telefon) kaydetmedi. Conditional Access "Require MFA" politikası varsa ilk girişte 14 gün grace period — sonra bloklanır.

  1. Kullanıcı mysignins.microsoft.com/security-info üzerinden MFA yöntemi ekleyebilir.
  2. Admin kullanıcıyı bilgilendirir + kullanıcı için "Set up security info" ilk girişte zorlanır.
  3. Bulk enrollment için: Entra → Identity Protection → MFA registration policy → bu kullanıcıyı kapsayan policy.

AADSTS65001 / AADSTS90094 — "Uygulama Consent Verilmedi"

Anlamı: Üçüncü taraf bir uygulama Microsoft 365 verilerine (e-posta, dosya, takvim) erişim istiyor ama kullanıcı veya admin onay vermemiş. 65001 kullanıcı consent, 90094 admin consent.

  1. Admin consent vermek için: Entra → Enterprise applications → uygulamayı bul → "Permissions" → "Grant admin consent for [tenant]" → onayla. Bu tenant'taki tüm kullanıcılar için bu uygulamayı yetkilendirir.
  2. Kullanıcı consent aktifse: Entra → Enterprise applications → "Consent and permissions" → "User consent settings" → "Allow user consent for verified publishers, for selected permissions".
  3. Kötü amaçlı uygulama şüphesi: Entra → Audit logs → "Consent to application" filtresi → son izinleri inceleyin. OAuth phishing saldırısıysa Entra → Enterprise applications → uygulamayı bul → "Delete".
  4. Çözüm dökümü kötü uygulanmış olabilir: Geliştirici tarafında uygulama manifest'inde gereksiz "Mail.ReadWrite" gibi yüksek izinler talep ediyor olabilir — least privilege prensibiyle gözden geçirin.

AADSTS70008 — "Authorization Code Süresi Doldu"

Anlamı: OAuth 2.0 authorization code akışında "code" 10 dakikada token'a değiştirilmedi. Geliştirici tarafı sorunu.

  1. OAuth akışında authorization code'u aldıktan sonra hemen /token endpoint'ine POST et — 10 dakika geçmeden.
  2. Saatler senkron mu? Sunucu saati 5+ dakika sapmış olabilir — NTP senkronize et.
  3. Code reuse yapmayın — her code tek seferlik. Refresh token ile yeni access token al.
  4. Test ortamından prod ortamına geçişte redirect_uri değişti mi kontrol et.

AADSTS500011 — "Resource Principal Bulunamadı"

Anlamı: Geliştirici uygulamasının scope parametresinde bahsettiği API kaynağı (resource) bu tenant'ta service principal olarak kayıtlı değil.

  1. Microsoft Graph kullanıyorsanız: scope https://graph.microsoft.com/.default şeklinde olmalı.
  2. Third-party API ise tenant'ta o uygulamanın "Enterprise application" kaydı olmalı. Entra → Enterprise applications → "All applications" → arama yap.
  3. Yoksa: POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?scope=offline_access ile consent akışı başlatın → service principal otomatik oluşur.

AADSTS530003 / 530005 — "Cihaz Uyumlu Değil"

Anlamı: Conditional Access politikası bu kullanıcı + uygulama kombinasyonu için "compliant cihaz" veya "Azure AD joined cihaz" şartı koyuyor. Mevcut cihaz Intune'da uyumlu değil veya domain'e join değil.

  1. Intune compliance status'unu kontrol et: Intune admin center → Devices → cihazı bul → "Compliance" tab → hangi politika fail oluyor (disk encryption, AV açık mı, password karmaşıklığı, vb.).
  2. Fail olan ayarı düzeltin (örn. BitLocker etkinleştir, Defender açık), cihaz check-in olduğunda yeşil olur (15-60 dakika).
  3. BYOD cihazlar için: Conditional Access exclude gerekirse: Entra → Security → Conditional Access → politikayı düzenle → "Conditions" → "Device platforms" → istisna ekle.
  4. Domain join cihaz şartı varsa: Cihazı Azure AD'e join et — Ayarlar → Hesaplar → "Access work or school" → "Connect" → iş hesabıyla giriş yap → "Register only this device".

AADSTS900561 — "İstek HTTP Yöntemi Yanlış"

Anlamı: OAuth endpoint'ine GET yerine POST gönderilmesi gereken bir istek yapıldı (veya tersi). Geliştirici hatası.

  1. /token endpoint'i ÖZELLIKLE POST bekler — request method'u kontrol et.
  2. /authorize endpoint'i GET bekler (browser redirect ile).
  3. Content-Type: application/x-www-form-urlencoded olmalı (application/json değil).

"AADSTS Hatasını Çözemiyorum" — Ne Zaman Profesyonel Destek?

Bazı AADSTS hataları sadece tenant düzeyinde yönetici müdahalesi gerektirir:

  • Conditional Access politikaları beklenmedik şekilde çoğu kullanıcıyı engelliyor — "What If" tool ile etki analizi, sonra geri alma kararı.
  • Federation service (AD FS) tarafındaki sorun — Azure AD Connect troubleshoot + token signing certificate yenileme.
  • Identity Protection "risky user" sınıflandırması yanlış — manual remediate + risk politikası ayarı.
  • MFA toplu reset — 100+ kullanıcının MFA enrollment'ı sıfırlanması gerek, PowerShell ile bulk işlem.
  • Token signing certificate rollover — federation'lı tenant'larda kritik, yanlış yapılırsa tüm tenant SSO çöker.

Sık Sorulan Sorular

AADSTS hata kodlarını nereden takip edebilirim?

Microsoft'un resmi listesi: login.microsoftonline.com/error?code=50058 (URL'deki code'u değiştirin). Türkçe açıklamalı liste için bu blog'taki tabloya bakın.

Conditional Access politikası neden bu kadar çok hataya sebep oluyor?

Conditional Access "kim, ne, nereden, hangi cihazla, hangi risk seviyesinde" kuralları belirler. Yanlış scope'lanmış politikalar (örn. "tüm kullanıcılar için MFA + uyumlu cihaz") yöneticiler dahil herkesi engelleyebilir. Mutlaka "Report-only" modda test edin, sonra "On" yapın. "Break glass" admin hesabı mutlaka Conditional Access dışında bırakın — yoksa tenant'a giremezsiniz.

MFA cihazımı kaybettim, nasıl giriş yaparım?

SSPR (Self-Service Password Reset) ile MFA reset aktifse aka.ms/sspr. Aktif değilse global admin'iniz Entra → Users → siz → "Authentication methods" → "Require re-register MFA" yapmalı. Tek admin tenant'ta admin'in MFA cihazını kaybetmesi felaket → "break glass" hesap şart.

Outlook'ta AADSTS hatası alıyorum, e-posta sorunu mu?

Outlook'taki AADSTS hataları kimlik doğrulama katmanı sorunudur, mail sunucusu değil. Modern Auth ile giriş yapıyorsanız Outlook hata kodları rehberine de bakın — orada Outlook'a özgü hata kodları detaylı.

Birden fazla kullanıcı aynı AADSTS hatasını alıyor, ne yapayım?

10+ kullanıcı aynı kodu alıyorsa sorun tenant geneli: Conditional Access politikası değişikliği, MFA registration kampanyası, Intune compliance politikası veya Identity Protection risk seviyesi yükseldi olabilir. Entra → Sign-in logs → hata kodu ile filtreleyin → "Conditional Access" tab → hangi politika kapatıyor görün. Yönetici desteğiniz yoksa yönetilen destek paketimiz 2 saat içinde tenant Conditional Access denetimi başlatır.

İlgili rehber: Conditional Access politikalarının (Block Legacy Auth, Trusted Locations, Risk-based, Privileged Role Protection) sıfırdan kurulumu, "What If" tool ile etki analizi ve "break-glass" admin koruması için Conditional Access Politika Rehberi blog yazısını okuyun. 6 politika örneği + PowerShell ile yönetim detaylı.

Sorunu Çözmek İçin Zaman Harcamak İstemiyor musun?

SLA'lı Hizmet

Bu rehberdeki adımlar her zaman işe yaramayabilir; bazen Microsoft 365 tenant'ında yönetici müdahalesi veya bir uzmanın bağlanması gerekir. KOBİ Başlangıç paketimiz (5-25 kullanıcı) ortalama 4 saatte ticket yanıtı, Standart ise sınırsız ticket + telefon desteği sunar. Aylık abonelik, tek seferlik fatura tuzağı yok.

Başlangıç · 5-25 kullanıcı Standart · 25-100 · En Popüler Premium · 100+ · 7/24 + TAM