OpenID कनेक्ट में ID टोकन समाप्ति समय का इरादा क्या है?

Question

ओपनआईडी कनेक्ट में एक एक्सेस टोकन की समाप्ति का समय होता है। प्राधिकरण कोड प्रवाह के लिए, यह आमतौर पर छोटा होता है (उदाहरण के लिए 20 मिनट) जिसके बाद आप नए टोकन का अनुरोध करने के लिए ताज़ा टोकन का उपयोग करते हैं।

आईडी टोकन भी एक समाप्ति समय है। मेरा प्रश्न यह है कि इसका आशय क्या है?

ताज़ा आईडी के समाप्ति समय से कम कोई भी आईडी टोकन समाप्ति समय का अर्थ होगा कि आपके पास अंततः एक समाप्त आईडी टोकन होगा, लेकिन एक वैध एक्सेस टोकन।

तो क्या आप निम्न हैं:

• अपनी आईडी को टोकन की समाप्ति की तुलना में अधिक समय तक समाप्त होने वाला टोकन दें
• एक्सेस टोकन के रूप में इसे उसी एक्सपायरी पर सेट करें और जब यह समाप्त हो जाए तो कुछ कार्रवाई करें (क्या?)
• बस रसीद पर अपने ग्राहक में आईडी टोकन का उपभोग करें, उसके बाद समाप्ति समय की उपेक्षा करें?

OpenID Connect ने विनिर्देश सिर्फ का कहना है कि जब सत्यापित करने में एक आईडी टोकन,

"The current time MUST be before the time represented by the exp Claim."

जो (संभवतः) ऊपर तीसरे विकल्प का समर्थन करता है।

---

संपादित करें

जैसा कि OpenID कनेक्ट OAuth2 पर बनाता है, नीचे दिए गए पूरक प्रश्न का उत्तर OAuth2 विनिर्देश में पाया जा सकता है , जो कहता है कि

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

---

एक संबंधित प्रश्न यह है कि जब आप टोकन के लिए एक प्राधिकरण कोड का आदान-प्रदान करते हैं, तो वही विनिर्देश कहता है कि आपको प्रतिक्रिया मिल सकती है जैसे:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

लेकिन इस मामले में "expires_in" का क्या संबंध है? पहुँच टोकन, ताज़ा टोकन या ID टोकन?

(जानकारी के लिए, IdentityServer3 इसे टोकन समाप्ति समय तक सेट करता है)।

Answer 1

मैं अपने स्वयं के प्रश्न का उत्तर दे रहा हूं जैसा कि पता चला है कि मेरे प्रश्न के पीछे की कुछ धारणाएं गलत थीं, इसलिए प्रश्न को फिर से लिखने के बजाय यहां स्पष्ट करना आसान है।

एक आईडी टोकन एक क्लाइंट को साबित करने के लिए होता है जिसे उपयोगकर्ता ने प्रमाणित किया है, और जिसके परिणामस्वरूप वे हैं।

जब एक क्लाइंट को आईडी टोकन प्राप्त होता है, तो यह आम तौर पर ऐसा कुछ करेगा जो इसे क्लेम्सआईडेंटिटी में बदल देगा, और इसे जारी रखेगा, जैसे कि कुकी का उपयोग करना।

आईडी टोकन को उपयोग के इस बिंदु पर अन-अवधि समाप्त हो जाना चाहिए (जो यह होना चाहिए, क्योंकि यह अभी जारी किया गया है)। लेकिन इसके बाद इसका फिर से उपयोग नहीं किया जाता है, इसलिए इससे कोई फर्क नहीं पड़ता कि यह समाप्त हो जाता है जबकि उपयोगकर्ता के पास अभी भी एक सक्रिय सत्र है। क्लाइंट के पास प्रमाणीकरण की आवश्यक जानकारी है, और बदले में उपयोगकर्ता को फिर से लॉग इन करने से पहले सत्र कितने समय तक रहता है, इसके लिए अपनी नीति चुन सकते हैं।

प्रश्न पूछते समय मेरी गलत धारणा यह थी कि एक आईडी टोकन और एक्सेस टोकन का एक साथ उपयोग किया जाना चाहिए, और इसलिए दोनों को वैध समाप्ति की तारीखों की आवश्यकता है। यह विभिन्न कारणों से गलत है:

• ID टोकन केवल एक ग्राहक को प्रमाणित करने के लिए हैं (जैसा कि ऊपर वर्णित है)।
• एक्सेस टोकन का ग्राहकों से कोई लेना-देना नहीं है। वे संसाधनों तक पहुंच के लिए हैं और एक क्लाइंट केवल उन्हें संभालता है यदि उसे संसाधन को कॉल करने की आवश्यकता होती है।
• स्टैंडअलोन MVC या WebForms एप्लिकेशन की तरह कुछ को केवल एक आईडी टोकन की आवश्यकता होती है। यदि यह बाहरी संसाधन नहीं कह रहा है, तो एक्सेस देने के लिए कुछ भी नहीं है, इसलिए कोई एक्सेस टोकन नहीं है।

Comments

क्या आपके पास इसके लिए कोई संदर्भ है? यूजीनियो का दावा है कि आप उसके जवाब में एक आईडी टोकन ताज़ा कर सकते हैं। क्या ये सच है?

— एंडीड जूल

आप एक आईडी टोकन को ताज़ा नहीं कर सकते हैं, इसकी समाप्ति का विस्तार करने के अर्थ में (जिस तरह से एक एक्सेस-टोकन को ऑफ़लाइन-एक्सेस टोकन का उपयोग करके ताज़ा किया जा सकता है)। लेकिन अगर आपके पास OpenID कनेक्ट प्रदाता (जैसे IdentityServer3 में लॉग इन करने के बाद एक कुकी) के साथ एक अनपेक्षित प्रमाणीकरण सत्र है, तो जब आप एक लॉगिन अनुरोध दोहराते हैं तो प्रदाता प्रमाणीकरण को छोड़ सकता है (क्योंकि कुकीज़ ने कहा है कि आपने किया है) और बस वापस लौटें नई आईडी टोकन (और यदि अनुरोध किया गया है, तो एक्सेस टोकन)। यह केवल तभी काम करता है जब कुकी में आईडी टोकन की तुलना में लंबा जीवनकाल होता है।

— अपराह्न

जब आप ऐसा कर सकते हैं, तो मुझे यकीन नहीं है कि क्या ऐसा करना सही है। यह एंड-यूज़र के लिए भी सहज नहीं होगा, क्योंकि इसके लिए मुट्ठी भर ब्राउज़र रीडायरेक्ट की आवश्यकता होगी।

— Kir

@Kir यदि आप एक जावास्क्रिप्ट एकल पृष्ठ ऐप (एसपीए) का उपयोग कर रहे हैं, तो एसीसी-टोकन नवीनीकरण पर पहला प्रयास आमतौर पर एक पृष्ठभूमि प्रक्रिया होगी, इसलिए अंत-उपयोगकर्ता बाधित नहीं होगा। उदाहरण के लिए, यदि आपके संसाधन का एपीआई जवाब देता है कि एक्सेस टोकन समाप्त हो गया है, तो एसपीए एक नए एक्सेस टोकन के लिए आइडेंटिटी सर्वर के लिए एक पृष्ठभूमि अनुरोध करता है। केवल तभी यह विफल हो जाता है (क्योंकि आईडी टोकन समाप्त हो गया है) क्या आपको उपयोगकर्ता को फिर से लॉगिन करने के लिए कहना होगा। उदाहरण के लिए github.com/IdentityServer/IdentityServer3.Samples/tree/master/… पर JavascriptImplicitClient नमूना देखें ।

— एपीटेयर

यदि आप OIdC प्रदाता समर्थन Refresh_token अनुरोध से इसे वापस करते हैं, तो आप Id_token को ताज़ा कर सकते हैं। देखें stackoverflow.com/questions/41168304/... और stackoverflow.com/questions/41741982/...

— माइकल Freidgeim

Answer 2

मुझे अपने स्वयं के कारणों के लिए इसे खोदना पड़ा और इसे लिखा, इसलिए मैं यहां जो कुछ सीखा, उसे पोस्ट करूंगा ...

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

उदाहरण के लिए, एक मोबाइल ऐप एक बैकएंड सेवा को बताने में सक्षम हो सकता है जो उपयोगकर्ता वह है जो ऐप का उपयोग कर रहा है और प्रारंभिक प्रमाणीकरण के बाद संक्षिप्त अवधि के बाद ऐसा करने की आवश्यकता हो सकती है, जिस समय आईडी टोकन समाप्त हो गया है; और इस प्रकार, उपयोगकर्ता को मज़बूती से प्रमाणित करने के लिए उपयोग नहीं किया जा सकता है।

इसलिए, जैसे एक्सेस टोकन (प्राधिकरण के लिए उपयोग किया जाता है - यह निर्दिष्ट करना कि उपयोगकर्ता के पास क्या अनुमतियाँ हैं ) को ताज़ा किया जा सकता है, क्या आप आईडी टोकन (प्रमाणीकरण के लिए उपयोग किया जाता है - यह निर्दिष्ट कर सकते हैं कि उपयोगकर्ता कौन है)? ओआईडीसी विनिर्देश के अनुसार, उत्तर स्पष्ट नहीं है। OIDC / OAuth में टोकन प्राप्त करने के लिए तीन "फ्लो" हैं, प्राधिकरण कोड फ्लो, इम्प्लिक्ट फ्लो और हाइब्रिड फ्लो (जो मैं नीचे छोड़ दूंगा क्योंकि यह अन्य दो का एक प्रकार है)।

OIDC / OAuth में निहित प्रवाह के लिए आप प्राधिकरण एंडपॉइंट में ID टोकन को प्राधिकरण एंडपॉइंट में उपयोगकर्ता को रीडायरेक्ट करके और अनुरोध पैरामीटर id_tokenके मान के रूप में सहित response_typeअनुरोध करते हैं। एक निहित प्रवाह सफल प्रमाणीकरण प्रतिक्रिया को शामिल करने के लिए आवश्यक है id_token।

के लिए प्रमाणीकरण कोड प्रवाह , ग्राहक निर्दिष्ट codeके मान के रूप response_typeअनुरोध पैरामीटर जब प्राधिकरण समाप्ति बिंदु को उपयोगकर्ता पुनः निर्देशित। एक सफल प्रतिक्रिया में एक प्राधिकरण कोड शामिल है। क्लाइंट क्लाइंट ऑथराइजेशन कोड के साथ टोकन एंडपॉइंट के लिए अनुरोध करता है और, OIDC कोर सेक्शन 3.1.3.3 के अनुसार सफल टोकन रिस्पॉन्स MUST में एक आईडी टोकन शामिल है ।

तो या तो प्रवाह के लिए, कि कैसे आप शुरू में आईडी टोकन प्राप्त करते हैं, लेकिन आप इसे कैसे ताज़ा करते हैं? OIDC धारा 12: रीफ़्रेश टोकन का उपयोग करना , रीफ़्रेश टोकन प्रतिक्रिया के बारे में निम्नलिखित कथन है:

रिफ्रेश टोकन के सफल सत्यापन पर, प्रतिक्रिया निकाय धारा 3.1.3.3 का टोकन रिस्पॉन्स है, सिवाय इसके कि इसमें एक id_token शामिल नहीं हो सकता है ।

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

Comments

यदि आप सामान्य प्राधिकरण प्रदाता के साथ काम करने के लिए एक सामान्य सॉफ़्टवेयर लिख रहे हैं, तो आप ताज़ा करने से id_token वापस करने पर भरोसा नहीं कर सकते। हालाँकि, यदि आप किसी विशेष प्रदाता (जैसे IdentityServer4) के साथ काम कर रहे हैं, तो आप इसकी क्षमता की जांच कर सकते हैं, और ताज़ा अनुरोध के बाद प्राप्त id_token का उपयोग कर सकते हैं

— माइकल फ्रीजिम

तो id_token को कैसे ताज़ा किया जा सकता है?

— जिल्वेके नोव

@jwilleke AFAIK, जैसा कि ऊपर कहा गया है "नई आईडी टोकन प्राप्त करने का एकमात्र तरीका उपयोगकर्ता को प्राधिकरण के समापन बिंदु पर पुनर्निर्देशित करके उपयोगकर्ता को फिर से अधिकृत / प्रमाणित करना है"

— स्कॉट विलेके

@MichaelFreidgeim दिलचस्प है, क्या आपका मतलब ओपन आईडी कनेक्ट डिस्कवरी तंत्र से है ? हम वास्तव में ऐसा कैसे करते हैं?

— स्कॉट विलेके

@ScottWilleke, मुझे यकीन नहीं है, क्या यह खोज से उजागर होता है। मैं विशेष प्रदाता पहचान के साथ काम कर रहा था Server4 और प्रलेखन से मुझे पता है, कि id_token ताज़ा से वापस आ गया है। आप अपने कोड की जांच कर सकते हैं, अगर यह वापस आ गया है, और, यदि नहीं, तो कुछ कमियां लागू करें।

— बजे माइकल फ्रीजिम

Answer 3

अगर मैं सही ढंग से समझ, के अनुसार इस और OpenID Connect ने कोर 1.0 कल्पना , जो अपने आप टोकन आईडी एक तंत्र सत्र लागू करने के लिए के रूप में कुकीज़ में संग्रहित किया जा सकता है, और क्लाइंट के लिए हर प्रमाणीकरण-की आवश्यकता होती है अनुरोध के साथ भेज दिया। क्लाइंट तब आईडी टोकन को स्थानीय रूप से या प्रदाता के सत्यापनकर्ता समापन बिंदु के माध्यम से सत्यापित कर सकता है (यदि प्रदान किया जाता है, जैसे Google करता है )। यदि टोकन की समय-सीमा समाप्त हो गई है, तो उसे prompt=noneURL पैरामीटर के साथ इस समय को छोड़कर एक और सामान्य अनुरोध करना चाहिए । id_token_hintपैरामीटर में एक्सपायर्ड आईडी टोकन भेजना भी सुनिश्चित करें , अन्यथा प्रदाता एक त्रुटि लौटा सकता है।

इसलिए, आईडी टोकन को समाप्त होना स्वाभाविक है, लेकिन prompt=noneयह सुनिश्चित करता है कि नई आईडी टोकन आसानी से बिना किसी उपयोगकर्ता के हस्तक्षेप के प्राप्त किया जा सकता है (जब तक कि उपयोगकर्ता उस ओपनआईडी से लॉग आउट न हो)।

Answer 4

यह एक ही इरादा है: आप id_tokenइसे समाप्त होने के बाद उपयोग नहीं कर सकते । मुख्य अंतर यह है कि id_tokenडेटा संरचना है और आपको किसी भी सर्वर या एंडपॉइंट को कॉल करने की आवश्यकता नहीं होगी, क्योंकि सूचना टोकन में ही एन्कोडेड है। एक नियमित रूप access_tokenसे आम तौर पर एक अपारदर्शी कलाकृति (एक GUID की तरह) होती है।

उपभोक्ता id_tokenको हमेशा इसकी (समय) वैधता की पुष्टि करनी चाहिए।

मैं आईएस से 100% परिचित नहीं हूं, लेकिन मुझे लगता है कि यह एक सुविधा क्षेत्र है। आपको हमेशा expदावे की जांच करनी चाहिए ।

समाप्ति वैधताओं में से एक है। id_tokens डिजिटल रूप से भी हस्ताक्षरित हैं और यह भी एक सत्यापन है जिसे आपको अवश्य करना चाहिए ।

Comments

धन्यवाद यूजीनियो मेरे पास मुख्य सवाल यह है कि आईडी टोकन समाप्त होने पर आपको क्या करना चाहिए? मैंने सोचा (संभवतः गलत तरीके से) कि एक अल्पकालिक पहुंच वाले टोकन को नवीनीकृत करने के लिए आप ताज़ा-टोकन का उपयोग करने के लिए एचएडी। लेकिन अगर आईडी-टोकन की एक्सेस-टोकन के समान समाप्ति है, तो आपके पास तुरंत एक समाप्त आईडी-टोकन होगा, इसलिए यह एक्सेस-टोकन को ताज़ा कर देगा। मुझे लगता है कि मुझे यहाँ कुछ याद आ रहा है!

— अप्पेरे

आप एक नया access_token या id_token प्राप्त करने के लिए (नॉन निरस्त) रिफ्रेश_टोकन का उपयोग करेंगे। या बस फिर से लॉगिन करने के लिए उपयोगकर्ता के रूप में। id_tokens, access_tokens के तार्किक रूप से समकक्ष हैं। बस एक अलग प्रारूप।

— यूजीनियो पेस

मेरी नवीनतम समझ यह है कि जब उपयोगकर्ता के पास प्रमाणीकरण सर्वर के साथ एक प्रमाणित सत्र होता है, जब एक्सेस टोकन 401 => 302 को समाप्त करता है, तो प्राधिकरण सर्वर को उपयोगकर्ता के हस्तक्षेप के बिना नया एक्सेस और आईडी टोकन मिलेगा। लेकिन ऑफलाइन मोड में एक रिफ्रेश_टोकन केवल एक नया एक्सेस_टोकन लौटाएगा जो कहता है कि किसी विशेष उपयोगकर्ता को कुछ संसाधन तक पहुंचने की अनुमति है। यह एक id_token नहीं लौटा सकता है, क्योंकि यह कहना होगा कि विशेष उपयोगकर्ता प्रमाणित है और ऑफ़लाइन मोड में ऐसा नहीं है।

— भूख

यह इस सवाल का एक बड़ा जवाब होगा कि id_token और access_token में क्या अंतर है (विशेषकर जब अपारदर्शी / संदर्भ टोकन का उपयोग करते हुए)। पहले प्रश्न का उत्तर देने पर ध्यान दें और फिर स्पष्ट करें कि टोकन और आईडी टोकन का उपयोग कैसे किया जाता है?

— ट्रेंट

Answer 5

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

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

में कोड प्रवाह आप ओपी के प्राधिकरण endpoint कहते हैं, और एक प्राप्त प्राधिकरण कोड (यह भी एक प्रमाणीकरण टोकन, या संक्षेप में authcode कहा जाता है)। यह समान कारणों से और प्राप्त नहीं किए जाने वाले id_token के समान समाप्त हो जाना चाहिए, जो आपको अंतर्निहित प्रवाह में प्राप्त हुआ है और इसे नवीनीकृत नहीं किया जाना चाहिए।

आपका UI या ऐप तब ओपी के टोकन एंडपॉइंट को कॉल करता है, और (ओपी के सर्वर पर अपने स्वामित्व वाले संसाधनों के उपयोग की अनुमति देने के लिए यूआई के माध्यम से उपयोगकर्ता की सहमति के बाद कभी-कभी) दोनों प्राप्त करता है:

• एक id_token, प्रमाणीकरण के लिए - जिसे सर्वर कॉल में फिर से उपयोग नहीं किया जाना चाहिए, लॉगआउट के दौरान संकेत के अलावा, जब इसकी समाप्ति अब महत्वपूर्ण नहीं है, और इसलिए, ऊपर दिए गए कारणों के लिए समाप्ति की अनुमति दी जानी चाहिए, और कभी भी ताज़ा नहीं किया जाना चाहिए।
• एक access_token - जो बाद में एपीआई कॉल करते समय, ओपी के UserInfo समापन बिंदु पर दिया जा सकता है। यह दावे लौटाएगा, और एपीआई तदनुसार अधिकृत कर सकता है।

आप इस access_token को रीफ़्रेश कर सकते हैं, क्योंकि यह केवल API को बताता है कि उपयोगकर्ता के पास क्या दावे हैं, और कौन से संसाधन (स्कोप और प्रत्येक स्कोप के दावे) उपयोगकर्ता आपको देने के लिए सहमत हैं। जैसा कि ऊपर बताया गया है कि उपयोगकर्ता द्वारा अब तक लॉग इन नहीं किए जाने के बाद भी एक्सेस की अनुमति है। बेशक आप id_token को फिर से ताज़ा करने की अनुमति कभी नहीं देना चाहते हैं, क्योंकि आप लॉग इन किए बिना प्रतिरूपण की अनुमति नहीं देना चाहते हैं।

Comments

अंतर्निहित प्रवाह के बारे में आपने जो कहा है वह आंशिक रूप से गलत है। एक क्लाइंट जो निहित प्रवाह का उपयोग करता है, एक आईडी टोकन के अलावा एक एक्सेस टोकन प्राप्त कर सकता है और उस एक्सेस टोकन का उपयोग सर्वर के साथ बातचीत करने के लिए कर सकता है।

— शॉन लुटिन

एक सामान्य प्रथा है, कि जब id_token समाप्त हो जाता है, तो क्लाइंट सर्वर से नए टोकन का अनुरोध करता है, ताकि उपयोगकर्ता को फिर से अधिकृत करने की आवश्यकता न हो। उदा। Damienbod.com/2017/06/02/…

— माइकल फ्रीजिम

Answer 6

मैं इस उत्तर को एक टिप्पणी के रूप में पोस्ट करना चाहता था, लेकिन चूंकि मैं स्टैकऑवरफ़्लो पर बहुत सक्रिय नहीं था, इसलिए मुझे लगता है कि मैं इसे वैकल्पिक उत्तर के रूप में पोस्ट कर रहा हूं।

जब आप उपयोगकर्ता को एक सत्र http://openid.net/specs/openid-connect-session-1_0.html से लॉग आउट करने के प्रयास के id_tokenरूप में उपयोग id_token_hintकरते हैं । मैं ईमानदारी से नहीं सोचता कि यह वास्तव में मायने रखता है अगर इस बिंदु पर समाप्त हो गया है क्योंकि आप केवल किसी विशेष उपयोगकर्ता को लॉग आउट करने के बारे में चिंतित हैं।id_token

Answer 7

TLDR;

यह जो कहता है, उस पर भरोसा करने से पहले आईडी टोकन सत्यापित करें

अधिक जानकारी

OpenID कनेक्ट में आईडी टोकन समाप्ति समय का इरादा क्या है?

इरादा क्लाइंट को आईडी टोकन को मान्य करने की अनुमति देता है, और ग्राहक को आईडी टोकन की जानकारी का उपयोग करने वाले कार्यों से पहले आईडी टोकन को मान्य करना होगा ।

से OpenID अंतर्निहित प्रवाह कल्पना :

यदि इस दस्तावेज़ में परिभाषित कोई भी सत्यापन प्रक्रिया विफल हो जाती है, तो आवश्यक जानकारी को सही ढंग से सत्यापित करने में विफल रहने वाली किसी भी कार्रवाई को समाप्त कर दिया जाना चाहिए और जरूरी नहीं कि जानकारी को मान्य किया जाए।

यह पुष्टि करने के लिए कि Google का OpenID कनेक्ट दस्तावेज़ ID टोकन सत्यापन के बारे में यह कहता है:

एक बात जो आईडी टोकन को उपयोगी बनाती है, वह यह है कि आप उन्हें अपने ऐप के विभिन्न घटकों के आसपास पास कर सकते हैं। ये घटक ऐप और उपयोगकर्ता को प्रमाणित करने वाले हल्के प्रमाणीकरण तंत्र के रूप में एक आईडी टोकन का उपयोग कर सकते हैं। लेकिन इससे पहले कि आप आईडी टोकन में जानकारी का उपयोग कर सकते हैं या उस पर भरोसा कर सकते हैं जो उपयोगकर्ता ने प्रमाणित किया है, आपको इसे सत्यापित करना होगा।

इसलिए, यदि हमारा क्लाइंट एप्लिकेशन आईडी टोकन की सामग्री के आधार पर कुछ कार्रवाई करने जा रहा है, तो हमें फिर से आईडी टोकन को मान्य करना होगा।