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

आइडेंटिटी प्रोवाइडर (आईडीपी) की ओर से जारी किया गया बेयरर टोकन (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 ईमेल आइडेंटिटी शामिल होती है.
...

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

delegate के लिए KACLS ऑथेंटिकेशन टोकन

ऑथेंटिकेशन टोकन में, JSON वेब टोकन (JWT) (JWT: RFC 7519) शामिल होता है. यह बेयरर ऑथेंटिकेशन टोकन है.

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

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

दावा
delegated_to

string

उस इकाई के लिए एक आइडेंटिफ़ायर जिसे ऑथेंटिकेशन डेलिगेट किया जाना है.

डेलिगेशन के संदर्भ में, ऑथेंटिकेशन टोकन में मौजूद resource_name दावे का इस्तेमाल, डेटा एन्क्रिप्शन की (डीईके) से एन्क्रिप्ट किए गए ऑब्जेक्ट की पहचान करने के लिए किया जाता है. यह डेलिगेशन, इस ऑब्जेक्ट के लिए मान्य होता है.

टोकन, Key Access Control List Service (KACLS) की ओर से Delegate कॉल का इस्तेमाल करके जारी किया जाता है. यह, KACLS की ओर से मान्य किए गए, सेल्फ़-साइन किए गए JWT हो सकते हैं. इसके अलावा, KACLS, भरोसेमंद कॉल के ज़रिए, किसी अन्य आईडीपी का इस्तेमाल करके भी ऐसा कर सकती है.

डेलिगेटेड ऑथेंटिकेशन टोकन को मान्य मानने के लिए, उसी कार्रवाई के लिए डेलिगेटेड ऑथराइज़ेशन टोकन उपलब्ध कराना ज़रूरी है. डेलिगेटेड ऑथराइज़ेशन टोकन, सामान्य ऑथराइज़ेशन टोकन जैसा ही होता है. हालांकि, इसमें 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)

उपयोगकर्ता का UTF-8 फ़ॉर्मैट वाला ईमेल पता.
iss

string

टोकन जारी करने वाला व्यक्ति या संगठन. इसकी तुलना, पुष्टि करने वाले भरोसेमंद लोगों या संगठनों के सेट से की जानी चाहिए.

aud

string

ऑडियंस, जैसा कि आईडीपी ने तय किया है. इसकी तुलना, लोकल कॉन्फ़िगरेशन से की जानी चाहिए.
exp

string

समाप्ति समय. इसकी जांच की जानी चाहिए.
iat

string

कार्ड जारी करने का समय. इसकी जांच की जानी चाहिए.
delegated_to

string

उस इकाई के लिए एक आइडेंटिफ़ायर जिसे ऑथेंटिकेशन डेलिगेट किया जाना है.
resource_name

string

डीईके से एन्क्रिप्ट किए गए ऑब्जेक्ट के लिए एक आइडेंटिफ़ायर. यह डेलिगेशन, इस ऑब्जेक्ट के लिए मान्य होता है.
...

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 में क्लाइंट-साइड एन्क्रिप्शन (सीएसई) कार्रवाइयों के लिए, इसकी वैल्यू kacls-migration होनी चाहिए.PrivilegedUnwrap
exp

string

समाप्ति समय.
iat

string

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

string

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

string

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

string

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

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