hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth से खाता हासिल करें

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करना चाहिए? सदस्यता योजनाएं की जांच करें!
• The PEASS Family की खोज करें, हमारा संग्रह विशेष NFTs
• आधिकारिक PEASS & HackTricks swag प्राप्त करें
• 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter 🐦@carlospolopm** का पालन करें**.
• हैकिंग ट्रिक्स साझा करें hacktricks repo और hacktricks-cloud repo को PR जमा करके।

मूलभूत जानकारी

OAuth के कुछ विभिन्न संस्करण हैं, आप https://oauth.net/2/ पर जाकर एक मूलभूत समझ प्राप्त कर सकते हैं।

इस लेख में, हम उस सबसे सामान्य प्रवाह पर ध्यान केंद्रित करेंगे जिसका आप आजकल सामना करेंगे, जो है OAuth 2.0 अधिकृती कोड ग्रांट प्रकार। सारांश में, OAuth डेवलपर्स को एक अधिकृती तंत्र प्रदान करता है जो किसी अन्य एप्लिकेशन (अधिकृती सर्वर) से आपके खाते के खिलाफ डेटा तक पहुंच या कुछ कार्रवाई करने की अनुमति देता है।

उदाहरण के लिए, मान लें वेबसाइट https://yourtweetreader.com में विशेषता है आपके द्वारा कभी भी भेजे गए सभी ट्वीट्स को प्रदर्शित करना, इसमें निजी ट्वीट्स भी शामिल हैं। इसके लिए, OAuth 2.0 का प्रयोग किया जाता है। https://yourtweetreader.com आपसे कहेगा कि उनके ट्विटर एप्लिकेशन को आपके सभी ट्वीट्स तक पहुंचने की अनुमति दें। एक सहमति पृष्ठ https://twitter.com पर उभरेगा जिसमें बताया जाएगा कि कौन सी अनुमतियां मांगी जा रही हैं, और उसका अनुरोध करने वाला डेवलपर कौन है। एक बार जब आप अनुमति देते हैं, https://yourtweetreader.com आपके ट्वीट्स तक पहुंच सकेगा।

OAuth 2.0 संदर्भ में महत्वपूर्ण तत्व:

• संसाधन मालिक: संसाधन मालिक वह उपयोगकर्ता/संगठन है जो अपने संरक्षित संसाधन, जैसे उनके ट्विटर खाते के ट्वीट्स, के लिए पहुंच प्रदान करता है। इस उदाहरण में, यह आप होंगे।
• संसाधन सर्वर: संसाधन सर्वर एक प्रमाणित अनुरोधों को संभालने वाला सर्वर है जो एप्लिकेशन ने संसाधन मालिक के लिए पहुंच टोकन प्राप्त करने के बाद प्राथमिकता देता है। इस उदाहरण में, यह होगा https://twitter.com
• क्लाइंट एप्लिकेशन: क्लाइंट एप्लिकेशन एक अनुमति का अनुरोध करने वाला एप्लिकेशन है जो संसाधन मालिक से अनुमति मांगता है। इस उदाहरण में, यह होगा https://yourtweetreader.com।
• अधिकृती सर्वर: अधिकृती सर्वर एक सर्वर है जो संसाधन मालिक की पहुंच को सफलतापूर्वक प्रमाणित करने के बाद पहुंच टोकन जारी करता है क्लाइंट एप्लिकेशन को। उपरोक्त उदाहरण में, यह होगा https://twitter.com
• client_id: client_id एक एप्लिकेशन के लिए पहचानकर्ता

https://twitter.com/auth
?response_type=code
&client_id=yourtweetreader_clientId
&redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback
&scope=readTweets
&state=kasodk9d1jd992k9klaskdh123

3. आपको सहमति पृष्ठ के साथ एक सहमति पृष्ठ पर प्रोम्प्ट किया जाएगा:

4. एक बार स्वीकार करने के बाद, ट्विटर redirect_uri के साथ code और state पैरामीटर के साथ एक अनुरोध भेजेगा:

https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh123

5. https://yourtweetreader.com फिर उस code को लेगी, और अपने एप्लिकेशन के client_id और client_secret का उपयोग करके, आपकी ओर से सर्वर से एक access_token प्राप्त करने के लिए एक अनुरोध करेगी, जिससे उन्हें आपकी सहमति प्राप्त की गई अनुमतियों तक पहुंच मिलेगी:

POST /oauth/access_token
Host: twitter.com
...{"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"}

6. अंत में, प्रवाह पूर्ण हो जाता है और https://yourtweetreader.com आपके access_token के साथ ट्विटर को API कॉल करेगा ताकि आपके ट्वीट्स तक पहुंच सकें।

बग बाउंटी खोज

अब, रोचक हिस्सा! OAuth के अंमलण में कई चीजें गलत हो सकती हैं, यहां मैं आमतौर पर देखने वाले बग की विभिन्न श्रेणियां हैं:

कमजोर redirect_uri कॉन्फ़िगरेशन

redirect_uri बहुत महत्वपूर्ण है क्योंकि अधिकृति के बाद इस URL के बाद संवेदनशील डेटा, जैसे कोड, जोड़ा जाता है। यदि redirect_uri किसी हमलावर्धक नियंत्रित सर्वर पर पुनर्निर्देशित किया जा सकता है, तो इसका अर्थ है कि हमलावर कोड का उपयोग करके पीड़ित के खाते को अधिकार में ले सकता है और पीड़ित के डेटा तक पहुंच सकता है।

इसे उत्पन्न करने का तरीका अधिकृति सर्वर द्वारा भिन्न होगा। कुछ केवल उसी निर्दिष्ट redirect_uri पथ को स्वीकार करेंगे लेकिन कुछ ऐसा करेंगे जो भी redirect_uri के डोमेन या उपनिर्देशिका में होगा, उसे स्वीकार करेंगे।

सर्वर द्वारा संभाले जाने वाले तर्क के आधार पर, redirect_uri को बाईपास करने के कई तकनीक हैं। एक स्थिति में जहां redirect_uri https://yourtweetreader.com/callback है, इनमें शामिल हैं:

• खुले रीडायरेक्ट: https://yourtweetreader.com/callback?redirectUrl=https://evil.com
• पथ ट्रावर्सल: https://yourtweetreader.com/callback/../redirect?url=https://evil.com
• कमजोर redirect_uri रेजेक्स: https://yourtweetreader.com.evil.com
• HTML इंजेक्शन और रेफरर हैडर के माध्यम से टोकन चोरी: https://yourtweetreader.com/callback/home/attackerimg.jpg

खुले रीडायरेक्ट के लिए संवेदनशील हो सकने वाले अन्य पैरामीटर हैं:

• client_uri - ग्राहक अनुप्रयोग के होम पेज का URL
• policy_uri - रिलायिंग पार्टी ग्राहक अनुप्रयोग द्वारा प्रदान किया गया URL ताकि अंत उपयोगकर्ता अपने प्रोफ़ाइल डेटा के बारे में पढ़ सकें।
• tos_uri - रिलायिंग पार्टी ग्राहक द्वारा प्रदान किया गया URL ताकि अंत उपयोगकर्ता रिलायिंग पार्टी की सेवा की शर्तों के बारे में पढ़ सकें।
• initiate_login_uri - एक तृतीय पक्ष द्वारा उपयोग किया जा सकने वाला https योजना का URI जिसका उपयोग RP द्वारा लॉगिन प्रारंभ करने के लिए किया जा सकता है। यह ग्राहक-साइड पुनर्निर्देशन के लिए उपयोग किया जाना चाहिए।

ये सभी पैरामीटर OAuth और OpenID निर्देशिकाओं के अनुसार वैकल्पिक हैं और हमेशा एक विशेष सर्वर पर समर्थित नहीं होते हैं, इसलिए यह हमेशा महत्वपूर्ण है कि आपके सर्वर पर कौन से पैरामीटर समर्थित हैं, उन्हें पहचानना।

यदि आप एक OpenID सर्वर को लक्ष्य बनाते हैं, तो डिस्कवरी अंतबिंदु पर **.well-known/openid-configuration** कुछ पैरामीटर शामिल हो सकते हैं जैसे "registration_endpoint", "request_uri_parameter_supported", और "require_request_uri_registration"। ये आपको पंजीकरण अंतबिंदु और अन्य सर्वर कॉन्फ़िगरेशन मानों को खोजने में मदद कर सकते हैं।

रीडायरेक्ट के अंमलण में XSS

जैसा कि इस बग बाउंटी रिपोर्ट https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html में उल्लेख किया गया है, संभवतः रीडायरेक्ट URL को सर्वर के प्रतिक्रिया में प्रतिबिंबित किया जा रहा है, जो XSS के लिए संवेदनशील हो सकता है। परीक्षण के लिए संभावित पेलोड:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - राज्य पैरामीटर के अनुचित हैंडलिंग

अक्सर, state पैरामीटर पूरी तरह से छोड़ दिया जाता है या गलत तरीके से उपयोग किया जाता है। यदि एक स्थिति पैरामीटर अस्तित्वहीन होता है, या एक स्थिर मान होता है जो कभी नहीं बदलता है, तो OAuth फ्लो बहुत संभावित रूप से CSRF के लिए संकटग्रस्त होगा। कभी-कभी, यदि state पैरामीटर होता है, तो एप्लिकेशन शायद ही पैरामीटर का कोई मान्यता प्रमाणीकरण नहीं करेगा और हमला काम करेगा। इसे उत्पन्न करने का तरीका यह होगा कि अपने खाते पर प्राधिकरण प्रक्रिया के माध्यम से जाएं और प्राधिकरण करने के बाद ठहरें। फिर आपको एक अनुरोध के साथ सामने आना होगा जैसे:

https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1

इस अनुरोध को प्राप्त करने के बाद, आप फिर इस अनुरोध को छोड़ सकते हैं क्योंकि ये कोड आमतौर पर एक बार का उपयोग होते हैं। फिर आप इस URL को एक लॉग इन किए हुए उपयोगकर्ता को भेज सकते हैं और यह आपके खाते को उनके खाते में जोड़ देगा। पहले इसे बहुत संवेदनशील नहीं लग सकता है क्योंकि आप बस अपने खाते को पीड़ित के खाते में जोड़ रहे हैं। हालांकि, कई OAuth कार्यान्वयन साइन-इन के उद्देश्य के लिए होते हैं, इसलिए यदि आप अपने Google खाते को जोड़ सकते हैं जो लॉग इन करने के लिए उपयोग किया जाता है, तो आप एकल क्लिक के साथ एक खाता हासिल कर सकते हैं क्योंकि अपने Google खाते से लॉग इन करने से आपको पीड़ित के खाते तक पहुंच मिल जाएगी।

इसके बारे में एक उदाहरण आप CTF writeup और HTB बॉक्स ओउच में देख सकते हैं।

मैंने कई बार देखा है कि राज्य पैरामीटर को एक अतिरिक्त पुनर्निर्देश मान माना जाता है। आवेदन redirect_uri का उपयोग प्राथमिक पुनर्निर्देश के लिए करेगा, लेकिन फिर state पैरामीटर को दूसरे पुनर्निर्देश के रूप में उपयोग करेगा जिसमें क्वेरी पैरामीटर में code हो सकता है, या रेफरर हेडर में हो सकता है।

एक महत्वपूर्ण बात यह है कि यह सिर्फ साइन-इन और खाता हासिल करने जैसी स्थितियों पर ही लागू नहीं होता है। मैंने देखा है कि गलतियों में:

• Slack एकीकरण एक हमलावर्धक को सभी सूचनाओं / संदेशों के प्राप्तकर्ता के रूप में अपना Slack खाता जोड़ने की अनुमति देते हैं
• स्ट्राइप एकीकरण एक हमलावर्धक को भुगतान जानकारी को अधिलेखित करने और पीड़ित के ग्राहकों से भुगतान स्वीकार करने की अनुमति देते हैं
• पेपाल एकीकरण एक हमलावर्धक को पीड़ित के खाते में अपना PayPal खाता जोड़ने की अनुमति देते हैं, जिससे हमलावर्धक के PayPal में पैसा जमा होगा

पहले खाता हासिल करने से पहले

मैं देखता हूं कि एप्लिकेशन्स "X के साथ साइन इन करें" की अनुमति देते हैं, लेकिन उपयोगकर्ता नाम / पासवर्ड भी होते हैं। इसे हमला करने के दो अलग-अलग तरीके हैं:

1. यदि एप्लिकेशन खाता बनाने पर ईमेल सत्यापन की आवश्यकता नहीं है, तो पहले ही पीड़ित के ईमेल पते और हमलावर्धक पासवर्ड के साथ एक खाता बनाने का प्रयास करें। यदि पीड़ित फिर तीसरे पक्ष जैसे Google के साथ रजिस्टर करने या साइन इन करने का प्रयास करता है, तो संभवतः एप्लिकेशन एक लुकअप करेगा, देखेगा कि ईमेल पहले से ही रजिस्टर है, और फिर उनके Google खाते को हमलावर्धक द्वारा बनाए गए खाते से लिंक करेगा। यह एक "पहले खाता हासिल करने" है जहां हमलावर्धक को पीड़ित के खाते तक पहुंच होगी यदि वह उसे पहले ही रजिस्टर कर देता है।
2. यदि OAuth ऐप ईमेल सत्यापन की आवश्यकता नहीं है, तो उस OAuth ऐप के साथ साइन अप करने की कोशिश करें और फिर ईमेल पते को पीड़ित के ईमेल पते के साथ बदलें। उपरोक्त की तरही समस्या हो सकती है, लेकिन आप इसे उलटी दिशा से हमला कर रहे होंगे और खाता हासिल करने के लिए पीड़ित के खाते में पहुंच प्राप्त कर रहे होंगे।

रहस्यों का खुलासा

यह बहुत महत्वपूर्ण है कि आप पहचानें कौन से OAuth पैरामीटर गोपनीय होते हैं, और उन्हें सुरक्षित रखें। उदाहरण के लिए, client_id लीक करना पूरी तरह से ठीक और आवश्यक है, लेकिन client_secret लीक होना खतरनाक होता है। यदि यह लीक हो जाता है, तो हमलावर्धक संभवतः विश्वसनीय ग्राहक ऐप्लिकेशन के विश्वसनीयता और पहुंच की पहचान चोरी करने के लिए विश्वसनीय ग्राहक ऐप्लिकेशन का दुरुपयोग कर सकता है। हमारे पहले उदाहरण पर वापस जाते हैं, मैंने देखा है कि इस कदम को क्लाइंट से किया जाता है, सर्वर से नहीं:

5. https://yourtweetreader.com _फिर उस code को ले लेगा, और अपने ऐप्लिकेशन के client_id और client_secret का उपयोग करके आपके लिए एक access_token प्राप्त करने के लिए सर्वर से एक अनुरोध करेगा, जिससे उन्हें आपकी सहमति

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer हेडर लीक कोड + स्थिति

जब क्लाइंट के पास कोड और स्थिति होती है, और यदि वह एक अलग पृष्ठ पर ब्राउज़ करते समय Referer हेडर में प्रतिबिंबित होती है, तो यह संकटपूर्ण हो सकता है।

ब्राउज़र इतिहास में संग्रहीत एक्सेस टोकन

ब्राउज़र इतिहास में जाएं और देखें कि क्या एक्सेस टोकन वहां संग्रहीत है।

अविनाशी प्राधिकरण कोड

प्राधिकरण कोड को केवल कुछ समय तक जीने की आवधि होनी चाहिए ताकि हमलावार आक्रमणकारी इसे चुरा और उपयोग कर सकें।

प्राधिकरण / ताजगी टोकन क्लाइंट से जुड़ा नहीं है

यदि आप प्राधिकरण कोड प्राप्त कर सकते हैं और इसे एक अलग क्लाइंट के साथ उपयोग कर सकते हैं, तो आप अन्य खातों को अधिकार में ले सकते हैं।

खुश पथ, XSS, आईफ्रेम और पोस्ट संदेश ताकत्वों को लीक करने के लिए कोड और स्थिति मानों को लीक करने के लिए

AWS Cognito

इस बग बाउंटी रिपोर्ट में: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ आप देख सकते हैं कि AWS Cognito उपयोगकर्ता को वापस देता है, जिसमें उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं। इसलिए, यदि आप एक अलग उपयोगकर्ता ईमेल के लिए उपयोगकर्ता ईमेल बदल सकते हैं, तो आप अन्य खातों को अधिकार में ले सकते हैं।

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

एवीएस कोग्निटो का दुरुपयोग कैसे करें के बारे में अधिक विस्तृत जानकारी के लिए देखें:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

दो लिंक और कुकी

इस लेख के अनुसार, एक हमलावर्धी के होस्ट की ओर इशारा करने वाले returnUrl के साथ एक पेज को पीड़ित को खोलना संभव था। यह जानकारी कुकी (RU) में संग्रहीत की जाएगी और एक बाद के चरण में प्रॉम्प्ट पूछेगा कि क्या उपयोगकर्ता उस हमलावर्धी के होस्ट को पहुंच देना चाहता है।

इस प्रॉम्प्ट को अनदेखा करने के लिए, एक टैब खोलना संभव था जिससे Oauth फ्लो शुरू होगा और यह RU कुकी returnUrl का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाई नहीं देगा, और इसके बाद एक नया टैब खोलेगा जिसमें वह मान्यता नहीं होगी। फिर, प्रॉम्प्ट हमलावर्धी के होस्ट के बारे में सूचित नहीं करेगा, लेकिन कुकी उसे सेट कर देगी, इसलिए टोकन हमलावर्धी के होस्ट पर भेजा जाएगा पुनर्निर्देशन में।

SSRF पैरामीटर

आप एक डायनेमिक क्लाइंट पंजीकरण अंत बिंदु को छूने के लिए छिपे हुए URL में से एक हैं। उपयोगकर्ताओं को सफलतापूर्वक प्रमाणित करने के लिए, ओआथ सर्वरों को ग्राहक एप्लिकेशन के बारे में विवरण जानने की आवश्यकता होती है, जैसे "client_name", "client_secret", "redirect_uris" आदि। ये विवरण स्थानीय विन्यास के माध्यम से प्रदान किए जा सकते हैं, लेकिन ओआथ अधिकृति सर्वरों के पास एक विशेष पंजीकरण अंत बिंदु भी हो सकता है। यह अंत बिंदु सामान्यतः "/register" के लिए मैप किया जाता है और निम्नलिखित प्रारूप के साथ POST अनुरोधों को स्वीकार करता है:

POST /connect/register HTTP/1.1
Content-Type: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...

{
"application_type": "web",
"redirect_uris": ["https://client.example.org/callback"],
"client_name": "My Example",
"logo_uri": "https://client.example.org/logo.png",
"subject_type": "pairwise",
"sector_identifier_uri": "https://example.org/rdrct_uris.json",
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/public_keys.jwks",
"contacts": ["ve7jtb@example.org"],
"request_uris": ["https://client.example.org/rf.txt"]
}

इस अनुरोध में पैरामीटरों को परिभाषित करने वाले दो विनिर्देश हैं: RFC7591 ओआथ के लिए और Openid Connect Registration 1.0 के लिए।

जैसा कि आप यहां देख सकते हैं, कई मानों को URL संदर्भ के माध्यम से पास किया जाता है और ये सर्वर साइड रिक्वेस्ट फॉर्जरी के लिए संभावित लक्ष्य लगते हैं। इसी बीच, हमने जितने भी सर्वरों का परीक्षण किया है, उनमें से अधिकांश सर्वर इन URL को तुरंत नहीं संग्रहीत करते हैं जब उन्हें एक पंजीकरण अनुरोध प्राप्त होता है। बजाय इसके, वे बस इन पैरामीटरों को सहेजते हैं और उन्हें ओआथ अधिकृति प्रवाह के दौरान बाद में उपयोग करते हैं। दूसरे शब्दों में, यह दूसरे क्रम की एसएसआरएफ है, जिससे काले-बॉक्स का पता लगाना मुश्किल हो जाता है।

इन पैरामीटरों में से निम्नलिखित पैरामीटर एसएसआरएफ हमलों के लिए विशेष रूप से रुचिकर हैं:

• logo_uri - एक URL जो एक क्लाइंट एप्लिकेशन के लिए एक लोगो को संदर्भित करता है। एक क्लाइंट को पंजीकृत करने के बाद, आप अपने नए "client_id" का उपयोग करके ओआथ अधिकृति अंत बिंदु ("/authorize") को कॉल करने का प्रयास कर सकते हैं। लॉगिन के बाद, सर्वर आपसे अनुरोध को मंजूरी देने के लिए पूछेगा और "logo_uri" से छवि प्रदर्शित कर सकता है। यदि सर्वर खुद छवि को फ़ेच करता है, तो इस चरण द्वारा एसएसआरएफ ट्रिगर होना चाहिए। वैकल्पिक रूप से, सर्वर केवल एक क्लाइंट-साइड "<img>" टैग के माध्यम से लोगो को शामिल कर सकता है। यदि URL नहीं भागा जाता है, तो यह एसएसआरएफ नहीं लेकिन एक्सएसएस हो सकता है अगर URL नहीं भागा जाता है।
• jwks_uri - क्लाइंट के JSON वेब कुंजी सेट [JWK] दस्तावेज़ के लिए URL। यह कुंजी सेट सर्वर पर आवेदित JWT का वैधीकरण करने के लिए आवश्यक होता है जब JWT का उपयोग करके ग्राहक प्रमाणीकरण के लिए टोकन अंत बिंदु पर बनाए गए अनुरोध किया जाता है [RFC7523]। इस पैरामीटर में एसएसआरएफ के लिए परीक्षण करने के लिए, एक दुष्ट "jwks_uri" के साथ एक नया क्लाइंट एप्लिकेशन पंजीकृत करें, किसी भी उपयोगकर्ता के लिए एक अधिकृति कोड प्राप्त करने के लिए अधिकृति प्रक्रिया का प्रदर्शन करें, और फिर निम्नलिखित बॉडी के साथ "/token" अंत बिंदु को फ़ेच करें:

POST /oauth/token HTTP/1.1
...
``
grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=eyJhbGci...

यदि संकटग्रस्त है, तो सर्वर को प्रदान की गई "jwks_uri" के लिए सर्वर-से-सर्वर एचटीटीपी अनुरोध करना चाहिए क्योंकि यह आपके अनुरोध में "client_assertion" पैरामीटर की मान्यता की जांच करने के लिए इस कुंजी की आवश्यकता होती है। यह शायद केवल एक अंधा एसएसआरएफ संकटग्रस्तता ही होगी, क्योंकि सर्वर को एक उचित JSON प्रतिक्रिया की उम्मीद होती है।

• sector_identifier_uri - यह URL एक फ़ाइल का संदर्भ करता है जिसमें एक एकल **JSON एरे ऑफ़ रीडायरेक्ट