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

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

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

string

आईडीपी के हिसाब से ऑडियंस. इसकी जांच लोकल कॉन्फ़िगरेशन के हिसाब से की जानी चाहिए.
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

आईडीपी के हिसाब से ऑडियंस. इसकी जांच लोकल कॉन्फ़िगरेशन के हिसाब से की जानी चाहिए.
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

आईडीपी के हिसाब से ऑडियंस. Google Drive में क्लाइंट-साइड एन्क्रिप्शन (सीएसई) PrivilegedUnwrap की कार्रवाइयों के लिए, यह kacls-migration होना चाहिए.
exp

string

समयसीमा खत्म होने का समय.
iat

string

कार्ड जारी करने का समय.
iss

string

टोकन जारी करने वाला. पुष्टि करने वाले भरोसेमंद लोगों के सेट के हिसाब से इसकी पुष्टि की जानी चाहिए. यह उस KACLS के KACLS_URL से मेल खाना चाहिए जिसने अनुरोध किया है. जारी करने वाले व्यक्ति या कंपनी के सार्वजनिक पासकोड का सेट यहां देखा जा सकता है: <iss>/certs.
kacls_url

string

मौजूदा KACLS का यूआरएल, जिस पर डेटा डिक्रिप्ट किया जा रहा है.
resource_name

string

डीईके से एन्क्रिप्ट (सुरक्षित) किए गए ऑब्जेक्ट के लिए आइडेंटिफ़ायर. ज़्यादा से ज़्यादा साइज़: 128 बाइट.
...

आपकी कुंजी ऐक्सेस कंट्रोल लिस्ट सेवा (केएसीएलएस), किसी भी अन्य दावे (जगह की जानकारी, कस्टम दावा वगैरह) का इस्तेमाल करके, पेरीमीटर का आकलन कर सकती है. इसके लिए, आपको कोई शुल्क नहीं देना होगा.