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

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

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 7516) होता है. यह एक बेयरर पुष्टि करने वाला टोकन होता है.

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

प्रतिनिधि के तौर पर पुष्टि करने वाला टोकन, सामान्य पुष्टि करने वाले टोकन की तरह ही होता है. इसमें एक और दावा शामिल होता है:

दावा
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 7516) है. इसे आइडेंटिटी पार्टनर (IdP) जारी करता है, ताकि उपयोगकर्ता की पहचान की पुष्टि की जा सके.

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

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

string

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

exp

string

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

iat

string

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

iss

string

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

kacls_url

string

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

resource_name

string

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

...

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