İçeriğe geç

OAuth2 ve OIDC — Şifreni Vermeden Nasıl Giriş Yapılır?

Orta 9 dk Çok sık karşılaşı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.

  1. Bayt: Bankacılık uygulamasına kurumsal hesapla giriş ekledim. Şifreyi uygulama hiç görmüyor!

  2. Sen: Peki dönüşte gelen kodu biri yakalarsa?

  3. Bayt: Kod... onu token'a çevirip hesaplara girebilir mi?

  4. 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.

Hızlı kontrolBaşlangıç

Authorization code akışında kullanıcı şifresini nereye girer?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

ID token ile access token arasındaki fark nedir?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

İ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.

Fiş, koçanı olmadan işe yaramaz.
Adım adım oku
  1. Şifre uygulamaya değil, resepsiyona söylenir.
  2. Resepsiyon bir fiş verir: kısa ömürlü kod.
  3. Uygulama fişi, yalnızca kendinde duran koçanla anahtara çevirir.
  4. 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.

Hızlı kontrolOrta

PKCE neyi durdurur?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

state parametresi neyi kanıtlar?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

Kendin gör

Şifreni vermeden giriş

Tohum 821143

Oynat ya da adımla.

Hız
Adım 0

Ş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.

  1. Varsayılanla oynat. Normal giriş: şifre uygulamaya hiç gelmedi.
  2. “Kodu ele geçirdi” seç, PKCE’yi kapat. Saldırgan token aldı.
  3. PKCE’yi aç. Token uç noktası reddetti.
  4. “Sahte dönüş linki” seç, state’i kapat. Kurban saldırganın hesabına girdi.
  5. state’i aç. Dönüş reddedildi.
Hızlı kontrolOrta

state kullanılmayan bir uygulamada saldırgan kurbana kendi kodunu taşıyan bir dönüş linki gönderdi. Kurban linke tıkladı. Ne olur?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

Mobil uygulama için neden PKCE zorunlu kabul edilir?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

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.

Hızlı kontrolOrta

Bir ekip API çağrılarında ID token'ı Authorization başlığına koyuyor. Sorun nedir?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

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
Proje dosyaları

src/main/resources/ application.yml İstemci kaydı: kimlik sağlayıcı, kapsamlar ve dönüş adresi.

src/main/resources/application.yml
spring:
security:
oauth2:
client:
registration:
bank-idp:
client-id: banking-web
client-secret: ${IDP_CLIENT_SECRET}
authorization-grant-type: authorization_code
scope: openid, profile, accounts.read
redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
provider:
bank-idp:
issuer-uri: https://id.bank.example

src/main/java/com/bank/web/ SecurityConfig.java Güvenlik ayarı: oauth2Login state'i kendisi üretir ve dönüşte karşılaştırır; PKCE gizli istemcide de açılıyor.

src/main/java/com/bank/web/SecurityConfig.java
@Configuration
class SecurityConfig {
@Bean
SecurityFilterChain web(HttpSecurity http, ClientRegistrationRepository registrations) throws Exception {
var resolver = new DefaultOAuth2AuthorizationRequestResolver(registrations, "/oauth2/authorization");
resolver.setAuthorizationRequestCustomizer(OAuth2AuthorizationRequestCustomizers.withPkce());
return http
.authorizeHttpRequests(auth -> auth.anyRequest().authenticated())
// oauth2Login generates and checks state on every sign-in
.oauth2Login(login -> login.authorizationEndpoint(ep -> ep.authorizationRequestResolver(resolver)))
.build();
}
}

src/main/java/com/bank/web/ AccountsClient.java API çağrısı: oturumdaki access token Authorization başlığına konuyor; ID token yalnızca kimliği okumak için.

src/main/java/com/bank/web/AccountsClient.java
@Component
class AccountsClient {
private final RestClient api;
AccountsClient(RestClient.Builder builder, OAuth2AuthorizedClientManager clients) {
this.api = builder
.baseUrl("https://api.bank.example")
// the access token travels; the ID token never leaves the web app
.requestInterceptor(new OAuth2ClientHttpRequestInterceptor(clients))
.build();
}
List<Account> myAccounts() {
return api.get().uri("/accounts").retrieve().body(new ParameterizedTypeReference<>() {});
}
}

accounts-api/src/main/resources/ application.yml API tarafı: yalnızca access token'ı doğrulayan bir resource server.

accounts-api/src/main/resources/application.yml
# The API accepts access tokens issued for it, nothing else.
spring:
security:
oauth2:
resourceserver:
jwt:
issuer-uri: https://id.bank.example
audiences: accounts-api

Kendini sına

Şimşek turu1/4

Authorization code akışında uygulama kullanıcının şifresini görür.

Soru 1/3İleri

Implicit akış neden artık önerilmiyor?

Cevabı biliyor musun?Önce birini seç. Tekrar zamanlaması buna göre ayarlanıyor.

Aklında kalacak üç şey

  1. 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. 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. 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.
Sonraki kapı Kullanıcı tablosu sızdı. Parolalar SHA-256 ile saklanıyordu. Saldırgan iki kullanıcının aynı parolayı kullandığını hemen gördü. Nasıl? Parola Saklama — Kullanıcı Tablosu Sızdı, Şimdi Ne Olacak? · 8 dk

4 kart sonraki derste seni bekliyor

0/4 kart bu dersten toplandı