Seri 1 — OIDC Nedir?

Bir uygulamaya girerken gördüğümüz giriş ekranı oldukça basittir bilgilerimizi girip kayıt oluruz fakat bu küçük ekranın arkasında kullanıcı kaydından parola sıfırlamaya, çok faktörlü doğrulamadan oturum güvenliğine kadar pek çok sorumluluk bulunur.

Bu yazıda önce bu sorumlulukların yazılım ekipleri için neden önemli olduğunu konuşacağız. Ardından adım adım daha teknik bir alana geçerek authentication, authorization, OAuth 2.0, OpenID Connect, token, JWT ve Identity Provider kavramlarını birbirinden ayıracağız.

Kısa cevap: OpenID Connect (OIDC), bir kullanıcının kimliğini uygulamalara standart ve güvenli bir yolla bildiren kimlik doğrulama katmanıdır. OAuth 2.0 üzerine kuruludur; fakat OAuth 2.0 ile aynı şey değildir.

Bu yazı kimler için?

Yazı; yazılım geliştiriciler, DevOps ve Platform Engineering ekiplerinin yanında proje yöneticileri ve teknik olmayan ekipler için de hazırlandı. Teknik kavramlar, günlük hayattaki karşılıkları kurulduktan sonra anlatılır.

1. Bir giriş ekranından fazlası

Yeni bir uygulama geliştirdiğimizi ve kullanıcıların giriş yapabilmesi için iki alan eklediğimizi düşünelim:

E-posta: [________________]
Parola:  [________________]

[ Giriş yap ]

İlk bakışta işimiz bitmiş gibi görünür. Oysa uygulamanın şu sorulara da doğru cevap vermesi gerekir:

• Parolalar nasıl saklanacak?
• “Parolamı unuttum” süreci nasıl korunacak?
• E-posta adresinin gerçekten kullanıcıya ait olduğu nasıl doğrulanacak?
• Üst üste hatalı parola deneyen biri nasıl engellenecek?
• Çok faktörlü kimlik doğrulama nasıl eklenecek?
• İşten ayrılan bir çalışanın bütün uygulamalardaki erişimi nasıl kaldırılacak?
• Açık oturumlar nasıl görüntülenecek ve gerektiğinde sonlandırılacak?

Dolayısıyla login ekranı, büyük bir sistemin yalnızca görünen yüzüdür.

Her uygulamanın kendi giriş sistemini kurması

Bir kurumda yalnızca bir uygulama varsa bu yük bir süre yönetilebilir görünebilir. Uygulama sayısı arttığında ise her ekip aynı problemi tekrar çözmeye başlar.

Bu yapıda bir şirketteki yazılım geliştirici ekip her kişi için 3 tane veritabanında aynı kullanıcının verisini gereksiz yere tutmak zorunda , dahası birinde yapılan en basit bir değişiklik geliştiricilerin gereksiz uğraşlara girmesine sebep olur.

Kurumsal şirketlerde bunun gibi daha birçok kullanıcıya yönelik işlem olduğu için kullanıcının giriş çıkış işlemlerini tek bir yerde incelemek gerekmektedir.

2. Authentication ve authorization aynı şey değildir

Kimlik sistemleri anlatılırken en sık karıştırılan iki kavram authentication ve authorization’dır.

Authentication: Sen kimsin?

Authentication, kullanıcının iddia ettiği kişi olduğunun doğrulanmasıdır. Türkçede genellikle kimlik doğrulama olarak kullanılır.

Bir sisteme e-posta ve parolayla giriş yapmak, telefona gelen kodu yazmak, parmak izi kullanmak veya passkey ile doğrulama yapmak authentication örnekleridir.

Authorization: Ne yapabilirsin?

Authorization, kimliği bilinen kişinin hangi kaynaklara erişebileceğinin ve hangi işlemleri yapabileceğinin belirlenmesidir. Türkçede yetkilendirme olarak kullanılır.

Günlük hayattan örnek: Ofis kartı

Ofis girişindeki görevli kimliğinize bakıp gerçekten çalışan olduğunuzu doğrular. Bu authentication’dır.

Daha sonra kartınız giriş katını açarken erişiminiz olmayan odaları açmayabilir. Hangi kapıları açabildiğiniz authorization’dır.

3. OAuth 2.0 hangi problemi çözer?

OAuth 2.0'ın çıkış noktası, bir uygulamanın başka bir sistemdeki veriye sınırlı erişim istemesidir.

Örneğin bir fotoğraf resolution booster (çözünürlük yükseltme) uygulaması bulut hesabınızdaki bazı fotoğrafları seçmesine izin vermek istediğinizi düşünün. Parolanızı baskı uygulamasına vermek kötü bir çözümdür. Çünkü uygulama parolanızı bilirse hesabınız üzerinde gereğinden fazla güce sahip olabilir.

OAuth 2.0 bunun yerine şu modeli sunar:

1. Fotoğraf uygulaması, bulut hizmetinden belirli bir erişim ister.
2. Bulut hizmeti size hangi erişimin istendiğini gösterir.
3. Onay verirseniz baskı uygulamasına sınırlı süreli ve sınırlı yetkili bir erişim anahtarı verilir.
4. Baskı uygulaması parolanızı hiç görmez.

4. Temel OAuth 2.0 akışları ve token yenileme

OAuth 2.0 tek bir akıştan ibaret değildir. Uygulamanın türüne ve ortada bir insan olup olmamasına göre farklı yöntemler kullanılır.

Authorization Code Flow

Web, mobil ve tek sayfa uygulamalarda kullanıcıyla giriş yapılan senaryoların temel akışıdır. Modern uygulamalarda PKCE ile birlikte kullanılır.

PKCE kısaca (Proof Key for Code Exchange), OAuth 2.0 yetkilendirme kodu akışında, bir saldırganın çalınan yetkilendirme kodunu kullanmasını önlemek için istemcinin rastgele bir “code verifier” üretip bunun hash’ini (“code challenge”) yetkilendirme isteğiyle gönderdiği ve token değişiminde orijinal verifier’ı ibraz ederek kimliğini kanıtladığı bir güvenlik uzantısıdır.

Akışın sade hali şöyledir:

authorization code, kısa ömürlü ve tek kullanımlık bir teslim fişi gibi düşünülebilir. Asıl token'ların tarayıcı adresinde taşınması yerine uygulama bu kodu token endpoint'inde değiştirir.

PKCE ise kodu başlatan uygulama ile kodu kullanacak uygulamanın aynı olduğunu doğrulamaya yardımcı olur. Bir saldırgan authorization code’u ele geçirse bile PKCE için gereken gizli doğrulayıcı olmadan kodu kullanamaz.

Bu akış yalnızca OAuth 2.0 kapsamında kullanıldığında sonuç access token’dır. İstek OIDC’nin openid scope'unu da içeriyorsa kimlik sağlayıcı ayrıca ID token üretir. İstek ile dönüş arasındaki ilişkinin korunması için state, yeniden oynatma ve token ilişkilendirme kontrolleri için de uygun durumda nonce kullanılır.

Client Credentials

Ortada bir son kullanıcı yoksa, iki sunucu kendi kimlikleriyle haberleşebilir. Örneğin gece çalışan bir raporlama servisi, faturalama API’sinden veri alabilir.

Bu akış bir kullanıcı girişi değildir. Token, bir insanı değil istemci uygulamayı temsil eder.

Device Authorization Flow

Akıllı televizyon, oyun konsolu veya komut satırı aracı gibi parola yazmanın zor olduğu cihazlarda kullanılır.

1. Cihaz ekranda kısa bir kod ve adres gösterir.
2. Kullanıcı telefonundan veya bilgisayarından bu adrese gider.
3. Kimliğini rahat bir cihazda doğrular ve kodu onaylar.
4. İlk cihaz giriş işleminin tamamlandığını öğrenir.

Bu yöntemde kullanıcı parolasını televizyon kumandasıyla yazmak zorunda kalmaz.

Refresh Token

Access token’lar güvenlik nedeniyle genellikle kısa ömürlüdür. Süre dolduğunda kullanıcıyı her seferinde yeniden giriş ekranına göndermek yerine, uygun istemcilere bir refresh token verilebilir.

Refresh token ayrı bir kullanıcı giriş akışı değildir; daha önce verilmiş yetki kapsamında oturumu sürdüren bir kimlik bilgisidir.

Refresh token API’ye gönderilmez; yeni token almak için yetkilendirme sunucusuna gönderilir. Uzun süre erişim sağlayabildiği için access token’dan daha dikkatli saklanmalıdır.

5. OAuth 2.0 neden tek başına giriş standardı değildir?

Bir access token aldığımızı düşünelim. Bu token bir API’ye erişim sağlayabilir; fakat OAuth 2.0 tek başına istemci uygulamaya şu soruların standart cevaplarını vermez:

• Giriş yapan kullanıcı kimdir?
• Kimlik doğrulama ne zaman yapıldı?
• Token hangi uygulama için üretildi?
• Kullanıcıya ait standart profil bilgileri nereden alınır?
• Sağlayıcının giriş, token ve imza anahtarı adresleri nasıl bulunur?

Geçmişte uygulamalar access token’ı okuyup bundan kullanıcı kimliği çıkarmaya veya sağlayıcıya özel API’ler çağırmaya başladı. Her sağlayıcının cevabı farklı olduğunda birlikte çalışabilirlik bozuldu.

İşte OpenID Connect bu boşluğu doldurur.

6. OpenID Connect ne ekler?

OpenID Connect, OAuth 2.0 üzerine eklenen bir kimlik katmanıdır. OAuth 2.0'ın güvenli yetki devri mekanizmasını kullanır ve uygulamanın giriş yapan kullanıcıyı standart biçimde tanımasını sağlar.

Bir OIDC isteği, openid scope'unu içerir. Bu küçük ifade, "yalnızca API erişimi istemiyorum; kullanıcının kimliğini de doğrulamak istiyorum" anlamına gelir.

OIDC’nin başlıca ekledikleri şunlardır:

ID Token

ID token, kimlik sağlayıcının istemci uygulama için ürettiği imzalı kimlik belgesidir. Kullanıcının kimliğine ilişkin claim’ler taşır.

En önemli nokta şudur:

ID token uygulama tarafından okunur ve doğrulanır; API çağırmak için access token yerine kullanılmaz.

UserInfo Endpoint

Uygulamanın kullanıcıya ait izin verilmiş profil bilgilerini standart biçimde alabileceği korumalı adrestir. Bu adrese access token ile gidilir.

Örneğin profile ve email scope'ları istenmişse ad, kullanıcı adı veya e-posta gibi bilgiler dönebilir. Sağlayıcı, izin ve gizlilik politikalarına göre bazı alanları döndürmeyebilir.

Discovery Endpoint

OIDC istemcisinin sağlayıcıya ait adresleri ve desteklenen özellikleri otomatik bulmasını sağlar. Yaygın adres şudur:

https://kimlik.example.com/.well-known/openid-configuration

Bu belgenin içinde genellikle şunlar bulunur:

• authorization_endpoint: Giriş ve onay sürecinin başladığı adres
• token_endpoint: Code'un token'larla değiştirildiği adres
• userinfo_endpoint: Kullanıcı profilinin alınabildiği adres
• jwks_uri: Token imzalarını doğrulayacak açık anahtarların adresi

Standard Claims

Claim, kimlik sağlayıcının bir konu hakkında bildirdiği ad-değer bilgisidir. OIDC sık kullanılan kimlik alanlarını standartlaştırır. Böylece her sağlayıcı için tamamen farklı bir veri modeli yazma ihtiyacı azalır.

7. OIDC akışı: Büyük resim

OIDC tarafındaki isimleri günlük dille eşleştirelim:

OIDC terimi Anlamı End User Giriş yapan kullanıcı OpenID Provider / Identity Provider Kullanıcıyı doğrulayan ve ID token üreten sistem Relying Party / Client Kimlik bilgisine güvenen uygulama Resource Server Access token ile korunan API

Aşağıdaki şema, Authorization Code Flow with PKCE kullanan tipik bir OIDC girişini özetler:

Bu akışta önemli bir ayrım vardır:

• Uygulama, ID token sayesinde kullanıcının giriş yaptığını anlar.
• API, access token sayesinde isteğin kendisine erişim hakkı olduğunu anlar.
• Uygulama, verilmişse refresh token sayesinde yeni bir access token isteyebilir.

Günlük hayattan örnek: Otel

Bir otelde resepsiyon kimliğinizi kontrol eder ve kaydınızı açar. Resepsiyon burada Identity Provider rolündedir.

• Size verilen üzerinde adınız ve konaklama bilginiz bulunan kayıt belgesi, uygulamanın sizi tanımasına yarayan ID token gibidir.
• Oda kartınız yalnızca izin verilen kapıları açar; bu access token gibidir.
• Konaklamanızı uzatırken yeni oda kartı almanızı sağlayan kayıt, refresh token benzetmesine yakındır.

Bu belgelerin amaçları farklıdır. Oda kapısını kimlik kayıt belgesiyle, kimlik kontrolünü de oda kartıyla yapmaya çalışmak doğru değildir.

8. Token ve JWT aynı şey midir?

Hayır. Token bir amaç ve kullanım bağlamıdır; JWT ise veriyi taşıyan bir formattır.

Bir biletin “konsere giriş bileti” olması amacını, PDF veya kâğıt olması ise formatını anlatır. Benzer biçimde ID token ve access token ne işe yaradığını, JWT ise bilginin nasıl paketlendiğini anlatır.

Token Temel amaç Hedef Biçim ID token Kullanıcının kimlik doğrulamasını uygulamaya bildirmek OIDC istemcisi JWT Access token Korunan kaynağa erişmek API / resource server JWT veya opaque olabilir Refresh token Yeni token istemek Authorization server Çoğunlukla opaque; biçime güvenilmez

Bir access token’ın JWT olduğu varsayılmamalıdır. Uygulama, sağlayıcının sözleşmesine göre hareket etmelidir.

9. JWT nedir?

JWT, claim’leri JSON biçiminde taşıyabilen bir token formatıdır. Yaygın imzalı gösterimi noktalarla ayrılmış üç bölümden oluşur:

xxxxx.yyyyy.zzzzz
  |     |     |
Header Payload Signature

Header

Token’ın nasıl imzalandığı ve hangi anahtarın kullanıldığı gibi teknik bilgileri taşır.

{
  "alg": "RS256",
  "kid": "key-2026-01",
  "typ": "JWT"
}

Payload

Claim’leri taşır. Aşağıdaki içerik yalnızca açıklayıcı bir örnektir:

{
  "iss": "https://kimlik.example.com",
  "sub": "user_8f31c2",
  "aud": "musteri-portali",
  "exp": 1785157200,
  "iat": 1785153600,
  "email": "ayse@example.com",
  "roles": ["editor"]
}

Signature

Header ve payload’ın yetkili tarafça üretildiğini ve sonradan değiştirilmediğini doğrulamaya yarar.

Çok önemli: İmzalı olmak şifreli olmak değildir

JWT’nin header ve payload bölümleri çoğunlukla Base64URL ile kodlanır. Bu bir şifreleme yöntemi değildir; içeriği kolayca okunabilir.

Bu nedenle token içine parola, kredi kartı numarası veya gereksiz kişisel veri konmamalıdır.

Sık kullanılan claim’ler

Claim Anlamı Kontrol / kullanım iss Token'ı üreten issuer Beklenen sağlayıcıyla tam eşleşmelidir sub Kullanıcının sağlayıcı içindeki kalıcı kimliği Kullanıcı eşleştirmesinde temel kimliktir aud Token'ın hedef kitlesi İlgili uygulama veya API'yi içermelidir exp Son kullanma zamanı Geçmişse token reddedilmelidir iat Üretilme zamanı Zaman ve olay incelemelerinde yardımcıdır nonce İstek ile ID token'ı ilişkilendiren değer OIDC istemcisi tarafından doğrulanır email Kullanıcının e-posta adresi Opsiyoneldir; kalıcı kullanıcı anahtarı yapılmamalıdır groups Grup üyelikleri Genellikle sağlayıcıya özel veya özel claim'dir roles Rol bilgileri Genellikle sağlayıcıya özel veya özel claim'dir

email, groups ve roles her sağlayıcıda aynı biçimde gelmeyebilir. Özellikle grup ve rol eşlemesi, uygulama ile Identity Provider arasında açıkça tasarlanmalıdır.

JWT yalnızca decode edilmez, doğrulanır

Bir token’ın payload bölümünü okuyabilmek, ona güvenmek için yeterli değildir. ID token doğrulanırken en azından şu kontroller yapılır:

1. İmza, sağlayıcının jwks_uri adresindeki uygun açık anahtarla doğrulanır.
2. iss beklenen kimlik sağlayıcıyla karşılaştırılır.
3. aud bu uygulamayı içeriyor mu kontrol edilir.
4. exp ile token'ın süresi kontrol edilir.
5. Akışta kullanıldıysa nonce doğrulanır.

Bu kontroller uygulamanın kendi yazdığı parçalı kodlarla değil, güvenilir ve güncel bir OIDC istemci kütüphanesiyle yapılmalıdır. Uygulama entegrasyonlarını Seri 2'de ayrıntılandıracağız.

JWT, OIDC’de tam olarak nerede kullanılır?

OIDC açısından JWT’nin en temel kullanım yeri ID token’dır. Kullanıcı Identity Provider’da doğrulandıktan ve uygulama authorization code’u token endpoint’inde değiştirdikten sonra Identity Provider, uygulamaya bir ID token verir. OIDC standardında bu ID token bir JWT’dir.

Uygulama JWT biçimindeki ID token’ın içindeki sub, iss, aud, exp, iat ve gerektiğinde nonce gibi claim'leri kullanarak şu sorulara cevap bulur:

• Token’ı beklediğim Identity Provider mı üretti?
• Token gerçekten benim uygulamam için mi üretildi?
• Token’ın kullanım süresi devam ediyor mu?
• Giriş isteği ile gelen cevap birbiriyle ilişkili mi?
• Identity Provider’ın doğruladığı kullanıcı hangi kalıcı kimliğe sahip?

Akışın JWT ile ilgili bölümü sade biçimde şöyledir:

Burada JWT uygulamanın kendi başına ürettiği bir giriş bileti değildir. Identity Provider tarafından imzalanmış bir kimlik bildirimidir. Uygulama yalnızca payload’ı okuyup kullanıcıyı içeri almamalı; imzayı ve ilgili claim’leri doğruladıktan sonra kendi güvenli oturumunu oluşturmalıdır.

OIDC akışında görülen her token’ın JWT olması da gerekmez. ID token JWT olmak zorundadır; access token JWT veya opaque olabilir. Access token’ın biçimine kaynak sunucusuyla yapılan sözleşme karar verir. Refresh token’ın iç yapısı ise istemci için anlam taşımamalı ve istemci onu yorumlamaya çalışmamalıdır. Dolayısıyla OIDC’de JWT denildiğinde ilk akla gelmesi gereken yer, kullanıcı kimliğini istemciye bildiren ID token’dır.

10. Identity Provider nedir?

Identity Provider (IdP), kullanıcıların kimliklerini ve giriş süreçlerini merkezi olarak yöneten sistemdir. OIDC bağlamında ID token üreten bu sistem için OpenID Provider adı da kullanılır.

Modern bir Identity Provider yalnızca parola kontrol etmez. Ürüne ve yapılandırmaya göre şu yetenekleri merkezi biçimde sunabilir:

• Kullanıcı ve hesap yaşam döngüsü
• Parola politikaları
• Çok faktörlü doğrulama
• Passkey ve passwordless giriş
• Sosyal hesaplarla giriş
• Kurumsal kimlik federasyonu
• SSO
• Oturum görüntüleme ve sonlandırma
• Rol, grup ve claim eşleme
• Güvenlik olayları ve audit kayıtları
• Uygulama ve makine kimlikleri

11. OIDC’nin getirdiği başlıca avantajlar

Merkezi kullanıcı yönetimi

Kullanıcının hesabı tek bir yerde yönetilir. İşe giriş, rol değişikliği, hesap kilitleme ve işten ayrılma süreçleri uygulama uygulama tekrarlanmaz.

Ortak güvenlik politikaları

Parola politikası, MFA zorunluluğu, riskli giriş kontrolü ve oturum süresi gibi kurallar merkezi uygulanabilir.

SSO

Kullanıcı Identity Provider’da geçerli bir oturuma sahipse bağlantılı başka bir uygulamaya yeniden parola girmeden geçebilir. Bu deneyime Single Sign-On denir.

SSO bir kullanıcı deneyimi ve oturum yeteneğidir; OIDC ise bu deneyimi kurmak için kullanılabilen protokollerden biridir.

Social Login ve Enterprise Login

Uygulamalar Google, Microsoft veya müşterinin kurumsal kimlik sistemiyle ayrı ayrı entegrasyon yapmak yerine merkezi sağlayıcıya bağlanabilir. Yeni bir harici sağlayıcı eklemek çoğu durumda uygulama kodundan çok Identity Provider yapılandırmasını etkiler.

Audit ve oturum yönetimi

Giriş denemeleri, başarısız doğrulamalar, MFA olayları ve aktif oturumlar merkezi olarak izlenebilir. Şüpheli bir durumda kullanıcının oturumları tek noktadan sonlandırılabilir.

Uygulamaların iş mantığına odaklanması

Uygulama ekipleri parola sıfırlama, MFA ekranı veya sosyal giriş bağlantıları gibi karmaşık güvenlik özelliklerini tekrar tekrar geliştirmek yerine ürünün asıl işlevlerine odaklanır.

12. OIDC ne değildir?

OIDC’yi doğru konumlandırmak için yapmadığı işleri de bilmek gerekir.

• OAuth 2.0'ın yerine geçen bir protokol değildir. OAuth 2.0 üzerine kimlik katmanı ekler.
• JWT ile aynı şey değildir. OIDC bir protokol, JWT ise bir token formatıdır.
• Tek başına bütün yetkilendirme modeliniz değildir. Uygulamanın iş kuralları ve kaynak bazlı izinleri yine tasarlanmalıdır.
• Token içeriğini otomatik olarak gizlemez. İmzalı JWT’nin payload’ı çoğunlukla okunabilir.
• Her token’ın JWT olmasını zorunlu kılmaz. ID token JWT’dir; access ve refresh token’ların biçimi sağlayıcının sözleşmesine bağlıdır.
• Yanlış uygulandığında güvenliği garanti etmez. Redirect URI, issuer, audience, imza, süre, state, nonce ve PKCE kontrolleri doğru yapılmalıdır.
• Identity Provider seçimini ortadan kaldırmaz. OIDC birlikte çalışabilirliği artırır; işletim, maliyet, yönetişim ve ürün kabiliyetleri yine değerlendirilir.

13. OIDC neden modern uygulamalarda standart hale geldi?

OIDC’nin yaygınlaşmasının nedeni yalnızca “tek giriş ekranı” sunması değildir. Asıl değer, kimlik doğrulamayı uygulama kodundan ayıran ortak bir sözleşme oluşturmasıdır.

Bir Java uygulaması, bir mobil uygulama ve bir Next.js uygulaması farklı teknolojiler kullanabilir. Yine de hepsi aynı discovery belgesini okuyabilir, aynı temel akışı uygulayabilir ve aynı claim dilini anlayabilir.

Bu standartlaşma:

• yeni uygulamaların daha hızlı devreye alınmasını,
• login kodunun tekrar tekrar yazılmamasını,
• güvenlik güncellemelerinin merkezileşmesini,
• farklı teknoloji yığınlarının aynı kimlik sistemiyle çalışmasını,
• sağlayıcı değişikliklerinin daha kontrollü yönetilmesini

sağlar.

Sonuç: Öğrendiğimiz kavramları akılda kalacak şekilde açıklayalım.

• Authentication: Kullanıcının kim olduğunu doğrular.
• Authorization: Kullanıcının veya istemcinin ne yapabileceğini belirler.
• OAuth 2.0: Bir kaynağa sınırlı erişim yetkisi devretmek için kullanılır.
• OIDC: OAuth 2.0 üzerine standart kullanıcı kimliği ve giriş katmanı ekler.
• ID token: Uygulamanın kullanıcıyı tanımasını sağlar.
• Access token: API’ye erişmek için kullanılır.
• Refresh token: Yeni token istemek için kullanılır.
• JWT: Claim’leri taşıyan bir formattır; şifreleme ile aynı şey değildir.
• Identity Provider: Kimlik, giriş, politika ve oturum süreçlerini merkezi ynetir.

Seri 2'de bu zihinsel modeli koda taşıyacak; Next.js, Java, Python ve PHP uygulamalarında login, logout, session, route koruması, rol kontrolü ve token doğrulamanın nasıl çalıştığını inceleyeceğiz.

Resmi kaynaklar

• OpenID Connect Core 1.0
• OpenID Connect Discovery 1.0
• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 9700 — Best Current Practice for OAuth 2.0 Security
• RFC 7636 — Proof Key for Code Exchange (PKCE)
• RFC 7519 — JSON Web Token (JWT)
• ZITADEL Documentation
• Keycloak Server Administration Guide
• Auth0 Documentation
• Okta — OAuth 2.0 and OpenID Connect
• Microsoft identity platform documentation
• Amazon Cognito user pools