OpenID Connect OAuth protokolini kengaytirib, asosiy OAuth ustida turadigan maxsus identifikatsiya va autentifikatsiya qatlamini beradi. U OAuth autentifikatsiyasini ishonchliroq va bir xil tarzda ishlashini ta'minlaydigan standartlashtirilgan funksiyalar qo'shadi.
U oddiy OAuth flow'lariga silliq joylashadi. Asosiy farq — barcha provayderlar uchun bir xil bo'lgan standartlashtirilgan scope'lar to'plami va qo'shimcha id_token response type. Rollar OAuth bilan bir xil, faqat atamalar biroz farq qiladi: Relying party (= client), End user (= resource owner), OpenID provider (= OpenID qo'llab-quvvatlaydigan OAuth xizmati).
"Claim" — resource serverdagi foydalanuvchi haqidagi key:value juftliklari (masalan "family_name":"Montoya"). Barcha OpenID xizmatlari bir xil scope to'plamidan foydalanadi. OpenID ishlatish uchun openid scope'i shart, so'ng profile, email, address, phone qo'shilishi mumkin.
OpenID Connect'ning yana bir qo'shilishi — id_token response type. U JSON web signature (JWS) bilan imzolangan JSON web token (JWT) qaytaradi. JWT payload dastlab so'ralgan scope asosidagi claim'lar ro'yxatini va foydalanuvchi qachon/qanday autentifikatsiya qilinganini o'z ichiga oladi. Bu client ilova va OAuth xizmati o'rtasidagi so'rovlar sonini kamaytiradi.
OpenID spetsifikatsiyasi client ilovalarning OpenID provayderda ro'yxatdan o'tishining standart yo'lini belgilaydi. Dynamic client registration qo'llab-quvvatlansa, client ilova /registration endpointga JSON tanali POST yuborib o'zini ro'yxatdan o'tkazadi:
POST /openid/register HTTP/1.1
Content-Type: application/json
Host: oauth-authorization-server.com
Authorization: Bearer ab12cd34ef56gh89
{
"application_type": "web",
"redirect_uris": ["https://client-app.com/callback"],
"client_name": "My Application",
"logo_uri": "https://client-app.com/logo.png",
"jwks_uri": "https://client-app.com/my_public_keys.jwks"
}OpenID provider client ilovadan autentifikatsiyani talab qilishi kerak. Biroq ba'zi provayderlar dynamic client registration'ni hech qanday autentifikatsiyasiz ruxsat beradi — bu hujumchiga o'z zararli client ilovasini ro'yxatdan o'tkazishga imkon beradi. Yuqoridagi ba'zi xususiyatlar (logo_uri, jwks_uri) URI ko'rinishida — agar OpenID provider ularga murojaat qilsa, bu ikkinchi bosqichli (second-order) SSRF'ga olib kelishi mumkin.
Ba'zi OpenID provayderlar parametrlarni query string o'rniga JWT sifatida uzatishga imkon beradi — bitta request_uri parametri qolgan OAuth parametrlarini o'z ichiga olgan JWT'ga ishora qiladi. Bu request_uri parametri yana bir potentsial SSRF vektori. Shuningdek, server query string'ni tekshirsa-da, JWT ichidagi parametrlarni (jumladan redirect_uri) tekshirmasligi mumkin.
