यह बियरर टोकन (JWT: RFC 7516) है. इसे आइडेंटिटी पार्टनर (IdP) जारी करता है, ताकि उपयोगकर्ता की पहचान की पुष्टि की जा सके.
JSON के काेड में दिखाना | |
---|---|
{ "aud": string, "email": string, "exp": string, "iat": string, "iss": string, "google_email": string, ... } |
फ़ील्ड | |
---|---|
aud |
आईडीपी के हिसाब से ऑडियंस. इसकी जांच, लोकल कॉन्फ़िगरेशन के हिसाब से की जानी चाहिए. |
email |
उपयोगकर्ता का ईमेल पता. |
exp |
समयसीमा खत्म होने का समय. |
iat |
कार्ड जारी करने का समय. |
iss |
टोकन जारी करने वाला. इसकी पुष्टि, पुष्टि करने वाले भरोसेमंद लोगों के सेट के हिसाब से की जानी चाहिए. |
google_email |
यह एक वैकल्पिक दावा है. इसका इस्तेमाल तब किया जाता है, जब इस JWT में मौजूद ईमेल दावा, उपयोगकर्ता के Google Workspace ईमेल आईडी से अलग होता है. इस दावे में, उपयोगकर्ता की Google Workspace ईमेल पहचान होती है. |
... |
आपकी कुंजी ऐक्सेस कंट्रोल लिस्ट सर्विस (केएसीएलएस), पेरीमीटर का आकलन करने के लिए किसी भी अन्य दावे (जगह की जानकारी, कस्टम दावा वगैरह) का इस्तेमाल मुफ़्त में कर सकती है. |
delegate
के लिए KACLS की पुष्टि करने वाला टोकन
पुष्टि करने वाले टोकन में JSON Web Token (JWT) (JWT: RFC 7516) होता है. यह एक बेयरर पुष्टि करने वाला टोकन होता है.
कभी-कभी कोई उपयोगकर्ता, सीधे तौर पर क्लाइंट पर पुष्टि नहीं कर पाता. इन मामलों में, उपयोगकर्ता किसी क्लाइंट को किसी खास संसाधन का ऐक्सेस दे सकता है. इसके लिए, पुष्टि करने वाला नया डेलिगेटेड टोकन जारी किया जाता है. इससे पुष्टि करने वाले ओरिजनल टोकन का दायरा सीमित हो जाता है.
प्रतिनिधि के तौर पर पुष्टि करने वाला टोकन, सामान्य पुष्टि करने वाले टोकन की तरह ही होता है. इसमें एक और दावा शामिल होता है:
दावा | |
---|---|
delegated_to |
उस इकाई के लिए आइडेंटिफ़ायर जिसे पुष्टि करने की प्रोसेस डेलिगेट करनी है. |
डेलिगेशन के संदर्भ में, पुष्टि करने वाले टोकन में मौजूद resource_name
दावे का इस्तेमाल, डेटा एन्क्रिप्शन की (डीईके) से एन्क्रिप्ट किए गए ऑब्जेक्ट की पहचान करने के लिए किया जाता है. यह डेलिगेशन के लिए मान्य होता है.
यह टोकन, Key Access Control List Service (KACLS) जारी करती है. इसके लिए, Delegate
कॉल का इस्तेमाल किया जाता है. यह ऐसे JWT हो सकते हैं जिन पर खुद के हस्ताक्षर किए गए हों और KACLS उनकी पुष्टि कर सकता हो. इसके अलावा, KACLS किसी भरोसेमंद कॉल के ज़रिए, किसी अन्य IdP का इस्तेमाल करके भी ऐसा कर सकता है.
डेलिगेट किए गए पुष्टि करने वाले टोकन को मान्य माना जाए, इसके लिए उसी कार्रवाई के लिए डेलिगेट किए गए अनुमति वाले टोकन का इस्तेमाल करना ज़रूरी है. डेलिगेट किए गए ऑथराइज़ेशन टोकन, सामान्य ऑथराइज़ेशन टोकन की तरह ही होता है. हालांकि, इसमें अतिरिक्त दावा delegated_to
शामिल होता है. delegated_to
और resource_name
के दावों की वैल्यू, डेलिगेट किए गए पुष्टि करने वाले टोकन में मौजूद वैल्यू से मेल खानी चाहिए.
हमारा सुझाव है कि आप डेलिगेट किए गए पुष्टि करने वाले टोकन के लिए, लाइफ़टाइम वैल्यू 15 मिनट पर सेट करें. इससे, लीक होने की स्थिति में टोकन का दोबारा इस्तेमाल होने से रोका जा सकेगा.
JSON के काेड में दिखाना | |
---|---|
{ "email": string, "iss": string, "aud": string, "exp": string, "iat": string, "google_email": string, "delegated_to": string, "resource_name": string ... } |
फ़ील्ड | |
---|---|
email |
उपयोगकर्ता का यूटीएफ़-8 फ़ॉर्मैट वाला ईमेल पता. |
iss |
टोकन जारी करने वाले की पुष्टि, पुष्टि करने वाले भरोसेमंद लोगों के सेट के हिसाब से की जानी चाहिए. |
aud |
आईडीपी के हिसाब से ऑडियंस. इसकी जांच, लोकल कॉन्फ़िगरेशन के हिसाब से की जानी चाहिए. |
exp |
समाप्त होने का समय, चुना जाना चाहिए. |
iat |
जारी करने का समय देखा जाना चाहिए. |
delegated_to |
उस इकाई के लिए आइडेंटिफ़ायर जिसे पुष्टि करने की प्रोसेस डेलिगेट करनी है. |
resource_name |
DEK से एन्क्रिप्ट (सुरक्षित) किए गए ऑब्जेक्ट के लिए आइडेंटिफ़ायर. इसके लिए, डेलिगेशन मान्य है. |
... |
KACLS, पेरीमीटर का आकलन करने के लिए, किसी भी अन्य दावे (जगह, कस्टम दावा वगैरह) का इस्तेमाल कर सकता है. |
PrivilegedUnwrap
के लिए KACLS की पुष्टि करने वाला टोकन
यह बियरर टोकन (JWT: RFC 7516) है. इसे आइडेंटिटी पार्टनर (IdP) जारी करता है, ताकि उपयोगकर्ता की पहचान की पुष्टि की जा सके.
इसका इस्तेमाल सिर्फ़ PrivilegedUnwrap
पर किया जाता है. PrivilegedUnwrap
के दौरान, अगर आईडीपी के पुष्टि करने वाले टोकन की जगह KACLS JWT का इस्तेमाल किया जाता है, तो KACLS पाने वाले व्यक्ति को सबसे पहले, जारी करने वाले व्यक्ति का JWKS फ़ेच करना होगा. इसके बाद, उसे टोकन के हस्ताक्षर की पुष्टि करनी होगी. इसके बाद, वह दावों की जांच कर पाएगा.
JSON के काेड में दिखाना | |
---|---|
{ "aud": string, "exp": string, "iat": string, "iss": string, "kacls_url": string, "resource_name": string ... } |
फ़ील्ड | |
---|---|
aud |
आईडीपी के हिसाब से ऑडियंस. Drive में क्लाइंट-साइड एन्क्रिप्शन (सीएसई) |
exp |
समयसीमा खत्म होने का समय. |
iat |
कार्ड जारी करने का समय. |
iss |
टोकन जारी करने वाला. इसकी पुष्टि, पुष्टि करने वाले भरोसेमंद लोगों के सेट के हिसाब से की जानी चाहिए. यह उस KACLS के |
kacls_url |
मौजूदा KACLS का यूआरएल, जिस पर डेटा डिक्रिप्ट किया जा रहा है. |
resource_name |
डीईके से एन्क्रिप्ट (सुरक्षित) किए गए ऑब्जेक्ट के लिए आइडेंटिफ़ायर. ज़्यादा से ज़्यादा साइज़: 128 बाइट. |
... |
आपकी कुंजी ऐक्सेस कंट्रोल लिस्ट सर्विस (केएसीएलएस), पेरीमीटर का आकलन करने के लिए किसी भी अन्य दावे (जगह की जानकारी, कस्टम दावा वगैरह) का इस्तेमाल मुफ़्त में कर सकती है. |