पुष्टि करने वाले टोकन

यह आइडेंटिटी प्रोवाइडर (आईडीपी) की ओर से जारी किया गया बियरर टोकन (JWT: RFC 7519) है. इसका इस्तेमाल, उपयोगकर्ता की पहचान की पुष्टि करने के लिए किया जाता है.

JSON के काेड में दिखाना
{ "aud": string, "email": string, "exp": string, "iat": string, "iss": string, "google_email": string, ... }

फ़ील्ड
aud	string आईडीपी (IdP) के हिसाब से ऑडियंस. इसकी जांच लोकल कॉन्फ़िगरेशन के हिसाब से की जानी चाहिए.
email	string (UTF-8) उपयोगकर्ता का ईमेल पता.
exp	string समयसीमा खत्म होने का समय.
iat	string कार्ड जारी करने का समय.
iss	string टोकन जारी करने वाला. पुष्टि करने वाले भरोसेमंद लोगों के सेट के हिसाब से इसकी पुष्टि की जानी चाहिए.
google_email	string यह एक वैकल्पिक दावा है. इसका इस्तेमाल तब किया जाता है, जब इस JWT में मौजूद ईमेल का दावा, उपयोगकर्ता के Google Workspace ईमेल आईडी से अलग होता है. इस दावे में, उपयोगकर्ता की Google Workspace ईमेल पहचान होती है.
...	की ऐक्सेस कंट्रोल लिस्ट सर्विस (केएसीएलएस), किसी भी अन्य दावे (जगह की जानकारी, कस्टम दावा वगैरह) का इस्तेमाल करके, पेरीमीटर का आकलन कर सकती है. इसके लिए, उसे कोई शुल्क नहीं देना होगा.

delegate के लिए KACLS की पुष्टि करने वाला टोकन

पुष्टि करने वाले टोकन में JSON Web Token (JWT) (JWT: RFC 7519) होता है. यह एक बियरर पुष्टि करने वाला टोकन होता है.

कभी-कभी, उपयोगकर्ता सीधे तौर पर क्लाइंट पर पुष्टि नहीं कर पाता. इन मामलों में, उपयोगकर्ता किसी संसाधन का ऐक्सेस, क्लाइंट को सौंप सकता है. इसके लिए, पुष्टि करने वाला नया डेलिगेटेड टोकन जारी किया जाता है. इससे पुष्टि करने वाले ओरिजनल टोकन का दायरा सीमित हो जाता है.

डेलिगेटेड ऑथेंटिकेशन टोकन, सामान्य ऑथेंटिकेशन टोकन की तरह ही होता है. इसमें एक और दावा शामिल होता है:

दावा
delegated_to	string उस इकाई के लिए आइडेंटिफ़ायर जिसे पुष्टि करने की प्रोसेस डेलिगेट करनी है.

डेलिगेशन के संदर्भ में, पुष्टि करने वाले टोकन में मौजूद 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	string (UTF-8) उपयोगकर्ता का यूटीएफ़-8 फ़ॉर्मैट वाला ईमेल पता.
iss	string टोकन जारी करने वाले की पुष्टि, भरोसेमंद पुष्टि करने वाले लोगों के सेट के हिसाब से की जानी चाहिए.
aud	string आईडीपी (IdP) के हिसाब से ऑडियंस. इसकी जांच लोकल कॉन्फ़िगरेशन के हिसाब से की जानी चाहिए.
exp	string समाप्त होने का समय, चुना जाना चाहिए.
iat	string जारी करने का समय, इसकी जांच की जानी चाहिए.
delegated_to	string उस इकाई के लिए आइडेंटिफ़ायर जिसे पुष्टि करने की प्रोसेस डेलिगेट करनी है.
resource_name	string DEK से एन्क्रिप्ट (सुरक्षित) किए गए ऑब्जेक्ट के लिए आइडेंटिफ़ायर. इसके लिए, डेलिगेशन मान्य है.
...	KACLS, पेरीमीटर का आकलन करने के लिए, किसी भी अन्य दावे (जगह, कस्टम दावा वगैरह) का इस्तेमाल कर सकता है.

PrivilegedUnwrap के लिए KACLS की पुष्टि करने वाला टोकन

यह आइडेंटिटी प्रोवाइडर (आईडीपी) की ओर से जारी किया गया बियरर टोकन (JWT: RFC 7519) है. इसका इस्तेमाल, उपयोगकर्ता की पहचान की पुष्टि करने के लिए किया जाता है.

इसका इस्तेमाल सिर्फ़ PrivilegedUnwrap पर किया जाता है. PrivilegedUnwrap के दौरान, अगर आईडीपी के ऑथेंटिकेशन टोकन की जगह KACLS JWT का इस्तेमाल किया जाता है, तो KACLS पाने वाले व्यक्ति को सबसे पहले, जारी करने वाले व्यक्ति के JWKS को फ़ेच करना होगा. इसके बाद, उसे टोकन के हस्ताक्षर की पुष्टि करनी होगी. इसके बाद, वह दावों की जांच कर पाएगा.

JSON के काेड में दिखाना
{ "aud": string, "exp": string, "iat": string, "iss": string, "kacls_url": string, "resource_name": string ... }

फ़ील्ड
aud	string आईडीपी (IdP) के हिसाब से ऑडियंस. Google Drive में क्लाइंट-साइड एन्क्रिप्शन (सीएसई) PrivilegedUnwrap की कार्रवाइयों के लिए, यह kacls-migration होना चाहिए.
exp	string समयसीमा खत्म होने का समय.
iat	string कार्ड जारी करने का समय.
iss	string टोकन जारी करने वाला. पुष्टि करने वाले भरोसेमंद लोगों के सेट के हिसाब से इसकी पुष्टि की जानी चाहिए. यह उस KACLS के KACLS_URL से मेल खाना चाहिए जिसने अनुरोध किया है. जारी करने वाले व्यक्ति या कंपनी के सार्वजनिक पासकोड का सेट यहां देखा जा सकता है: <iss>/certs.
kacls_url	string मौजूदा KACLS का यूआरएल, जिस पर डेटा डिक्रिप्ट किया जा रहा है.
resource_name	string डीईके से एन्क्रिप्ट (सुरक्षित) किए गए ऑब्जेक्ट के लिए आइडेंटिफ़ायर. ज़्यादा से ज़्यादा साइज़: 128 बाइट.
...	की ऐक्सेस कंट्रोल लिस्ट सर्विस (केएसीएलएस), किसी भी अन्य दावे (जगह की जानकारी, कस्टम दावा वगैरह) का इस्तेमाल करके, पेरीमीटर का आकलन कर सकती है. इसके लिए, उसे कोई शुल्क नहीं देना होगा.