OAuth2 ve OIDC — Şifreni Vermeden Nasıl Giriş Yapılır?
Önce şunu oku: Spring Security Filter Chain
30 saniyede özet
Authorization code akışında şifre yalnızca kimlik sağlayıcıya girilir; uygulama bir kod alır ve onu token'lara çevirir. state sahte dönüşleri, PKCE çalınan kodları durdurur. ID token kim olduğunu, access token neye erişebildiğini söyler.
Bir otelde odana girmek için evinin anahtarını resepsiyona bırakmazsın. Kim olduğunu resepsiyonda kanıtlarsın, eline yalnızca o odayı açan, süresi dolan bir kart verilir. Bir uygulamaya “Google ile giriş” yaptığında olan da budur.
-
Bayt: Bankacılık uygulamasına kurumsal hesapla giriş ekledim. Şifreyi uygulama hiç görmüyor!
-
Sen: Peki dönüşte gelen kodu biri yakalarsa?
-
Bayt: Kod... onu token'a çevirip hesaplara girebilir mi?
-
Bayt: Akışın iki küçük parametresi tam bunun için var. Adım adım bakalım.
Şifre yalnızca bir yerde
OAuth2Bir uygulamanın, kullanıcının şifresini görmeden onun adına erişim almasını sağlayan yetkilendirme çerçevesi. Şifre yalnızca kimlik sağlayıcıya girilir.Sözlükte gör → ile giriş yaparken uygulama seni kimlik sağlayıcıya yönlendirir; şifreni yalnızca orada girersin. Kimlik sağlayıcı seni uygulamaya kısa ömürlü bir kodla geri gönderir.
Uygulamanın sunucusu bu kodu token’lara çevirir. OpenID Connect ile gelen ID tokenOpenID Connect'in uygulamaya verdiği, kimin giriş yaptığını söyleyen imzalı token. API çağrıları için değil, uygulamanın kendisi içindir.Sözlükte gör → kimin giriş yaptığını söyler; access token ise API çağrılarında kullanılır.
Kafam karıştı, daha basit anlat
Şifre yalnızca kimlik sağlayıcıya girilir. Uygulama bir kod alır ve onu token’lara çevirir.
Authorization code akışında kullanıcı şifresini nereye girer?
ID token ile access token arasındaki fark nedir?
İki küçük parametre
Telefondaki kötü niyetli bir uygulama, bankacılık uygulamasının dönüş adresindeki kodu yakaladı. Akışta PKCE kullanılmıyor. Saldırgan bu kodla token alabilir mi? Cevabı göster
Evet. Kodu token’a çevirirken, kodu kimin başlattığını kanıtlayan hiçbir şey istenmiyor. Kodu bulan herkes onu kullanabilir.
Adım adım oku
- Şifre uygulamaya değil, resepsiyona söylenir.
- Resepsiyon bir fiş verir: kısa ömürlü kod.
- Uygulama fişi, yalnızca kendinde duran koçanla anahtara çevirir.
- Fişi çalan biri, koçan olmadan anahtar alamaz.
PKCEProof Key for Code Exchange: girişi başlatan uygulamanın ürettiği doğrulayıcı. Kodu token'a çevirmek için gerekir; çalınan kod tek başına işe yaramaz.Sözlükte gör → ile uygulama girişi başlatırken rastgele bir doğrulayıcı üretir ve kimlik sağlayıcıya yalnızca onun özetini gönderir. Kodu çevirirken doğrulayıcının kendisi istenir; çalınan kod tek başına işe yaramaz.
state ise girişi başlatırken üretilen rastgele bir değerdir. Dönüşte aynı değer gelmezse dönüş reddedilir; böylece saldırganın kendi kodunu taşıyan sahte bir link seni onun hesabına sokamaz.
Kafam karıştı, daha basit anlat
PKCE çalınan kodu, state sahte dönüşü durdurur. İkisi de girişi başlatanın elindeki küçük bir sırdır.
PKCE neyi durdurur?
state parametresi neyi kanıtlar?
Kendin gör
Şifreni vermeden giriş
Tohum 821143Oynat ya da adımla.
Şu an ne oldu?
Normal giriş
Şifre yalnızca kimlik sağlayıcıya girilir; uygulama bir kod alır ve onu token'lara çevirir.
Görevler0/3
Çalınan bir kodu saldırganın token'a çevirmesine izin veraçık
İpucu
Kodu kimin başlattığının kanıtını kaldır.
Kurbanı saldırganın hesabına sokturtaçık
İpucu
Sahte dönüş linki ve eksik bir kontrol.
İki saldırıyı da aynı ayarlarla durduraçık
İpucu
İki parametre de açık olsun; iki senaryoyu da dene.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Normal giriş: şifre uygulamaya hiç gelmedi.
- “Kodu ele geçirdi” seç, PKCE’yi kapat. Saldırgan token aldı.
- PKCE’yi aç. Token uç noktası reddetti.
- “Sahte dönüş linki” seç, state’i kapat. Kurban saldırganın hesabına girdi.
- state’i aç. Dönüş reddedildi.
state kullanılmayan bir uygulamada saldırgan kurbana kendi kodunu taşıyan bir dönüş linki gönderdi. Kurban linke tıkladı. Ne olur?
Mobil uygulama için neden PKCE zorunlu kabul edilir?
Tuzaklar
API’ye ID token göndermek. ID token uygulama içindir ve “kim” sorusunu cevaplar. API, kendisi için çıkarılmış ve yetkileri taşıyan access token bekler.
Implicit akışı kullanmak. Token’ı doğrudan tarayıcının adres çubuğuna koyan eski implicit akış artık önerilmiyor. Tarayıcı uygulamaları da authorization code ve PKCE kullanır.
Gizli anahtarı istemciye koymak. Mobil uygulama ya da tarayıcı kodu bir sır saklayamaz; içindeki client secret herkesindir. Bu yüzden onlar için PKCE zorunludur.
Kafam karıştı, daha basit anlat
API’ye access token gönder, implicit akışı kullanma, istemci koduna sır koyma.
Bir ekip API çağrılarında ID token'ı Authorization başlığına koyuyor. Sorun nedir?
Aşağıdaki örnek bir bankanın web uygulamasından: Spring Security girişi kimlik sağlayıcıyla yapıyor, state’i kendisi üretiyor, PKCE açık, API’ye yalnızca access token gidiyor.
Derinleş · Banka web uygulaması: authorization code, state ve PKCE 4 dosya · ~54 satır · ilk okumada atlayabilirsin
Kendini sına
Authorization code akışında uygulama kullanıcının şifresini görür.
Implicit akış neden artık önerilmiyor?
Aklında kalacak üç şey
- 1 Authorization code akışında şifre yalnızca kimlik sağlayıcıya girilir. Uygulama dönüşte bir kod alır ve sunucusu bu kodu token'lara çevirir.
- 2 state, girişi uygulamanın kendisinin başlattığını kanıtlar ve sahte dönüş linklerini durdurur. PKCE, kodu çevirebilmek için yalnızca girişi başlatanın bildiği bir doğrulayıcı ister; çalınan kod tek başına işe yaramaz.
- 3 ID token uygulamaya kimin giriş yaptığını söyler; access token API çağrılarında kullanılır. API'ye ID token gönderilmez.
4 kart sonraki derste seni bekliyor