सुरक्षा बंडल

इस गाइड में, ऐसी सुविधाओं के बारे में बताया गया है जो Google खाते के बारे में भरोसेमंद सिग्नल देती हैं. इन भरोसेमंद सिग्नल से, खाता मैनेज करने वाले सिस्टम को साइन अप करने, खाता बनाने, और बाद में वापस आने वाले उपयोगकर्ताओं के लिए जोखिम के आधार पर फ़ैसले लेने में मदद मिलती है.

सेशन

किसी ऐप्लिकेशन से पुष्टि करने के लिए किए गए अनुरोध पर, आईडी टोकन मिलता है. उदाहरण के लिए, जब 'Google से साइन इन करें' बटन दबाया जाता है, तो Android, iOS या वेब क्लाइंट या सर्वर ऐप्लिकेशन को आईडी टोकन वापस भेज दिया जाता है.

Google खाते में साइन-इन करने के लिए पुष्टि करना, एक अलग इवेंट है. आईडी टोकन में दिखाए गए दावे, इस इवेंट के बारे में बताते हैं. उदाहरण के लिए, Google खाते में साइन इन करने के लिए इस्तेमाल किया गया समय और तरीके.

पुष्टि करने के दो चरण और उपयोगकर्ता के दो सेशन होते हैं:

  • उपयोगकर्ता <-> Google सेशन यह तब सेट होता है, जब कोई उपयोगकर्ता अपने Google खाते में साइन इन करता है. Google इस सेशन के लाइफ़साइकल और सुरक्षा को मैनेज करता है. auth_time और amr दावे, आपको इस सेशन के बारे में अहम जानकारी देते हैं.
  • उपयोगकर्ता <-> आपके ऐप्लिकेशन का सेशन यह तब बनता है, जब उपयोगकर्ता आपके ऐप्लिकेशन में साइन इन करता है. इसे अक्सर 'Google से साइन इन करें' सुविधा का इस्तेमाल करके शुरू किया जाता है. आपका ऐप्लिकेशन, इस सेशन को मैनेज करता है. इसके लिए, वह दावों का इस्तेमाल करता है, ताकि सेशन और खाता मैनेजमेंट से जुड़े फ़ैसलों को बेहतर बनाया जा सके.

उपयोगकर्ता अक्सर फ़ोन, डेस्कटॉप कंप्यूटर, स्मार्ट डिसप्ले या टीवी जैसे कई डिवाइसों पर Google की सेवाओं का इस्तेमाल करते हैं. हर प्लैटफ़ॉर्म या डिवाइस पर साइन इन करने से, एक अलग सेशन शुरू होता है. वेब पर साइन इन करने के लिए, किसी ब्राउज़र और Google के बीच एक सेशन बनाया जाता है. ध्यान दें कि निजी ब्राउज़िंग और गुप्त मोड, अपने अलग-अलग सेशन बनाते हैं. इस वजह से, एक Google खाते से अलग-अलग ब्राउज़र और डिवाइसों पर एक साथ कई सेशन चालू हो सकते हैं. ज़्यादा जानकारी के लिए, खाते का ऐक्सेस रखने वाले डिवाइसों की जानकारी देखना लेख पढ़ें.

Google खाते की स्थिति

Google खाते के लाइफ़साइकल के सामान्य इवेंट ये हैं:

इस गाइड में बताई गई Security Bundle की सुविधाएं, चालू या बंद किए गए खातों पर लागू होती हैं. हालांकि, ये सुविधाएं Google खाता बनाने या मिटाने की घटनाओं पर लागू नहीं होती हैं.

Google किसी भी समय किसी खाते को बंद कर सकता है. इसके कुछ कारण यहां दिए गए हैं: आपका खाता बंद कर दिया गया है. ऐसा होने पर, Google के सभी चालू सेशन बंद हो जाते हैं. साथ ही, Google की क्रॉस-अकाउंट सुरक्षा सेवा, RISC इवेंट भेजती है. बंद किए गए खातों को 'Google से साइन इन करें' सुविधा का इस्तेमाल करने से रोक दिया जाता है. इसका मतलब है कि आईडी टोकन कभी जारी नहीं किया जाता. इसलिए, इसका इस्तेमाल बंद किए गए उपयोगकर्ता खातों की निगरानी के लिए नहीं किया जा सकता.

क्रॉस-अकाउंट सुरक्षा (आरआईएससी) इवेंट पाना ज़रूरी नहीं है. हालांकि, ये इवेंट उपयोगकर्ता और आपके ऐप्लिकेशन के बीच सेशन को मैनेज करने के लिए अहम सिग्नल के तौर पर काम करते हैं. साथ ही, यह भी तय करते हैं कि सेशन को सुरक्षित रखना है या नहीं. आरआईएससी को लागू करने और इवेंट का जवाब देने के तरीके के बारे में निर्देश, क्रॉस-अकाउंट सुरक्षा की मदद से उपयोगकर्ता खातों को सुरक्षित रखें लेख में दिए गए हैं.

सेटअप

ज़्यादा दावे पाने के लिए, आपके ऐप्लिकेशन का पब्लिश होना, पुष्टि किया जाना, और सुरक्षा बंडल की सुविधाएं चालू होना ज़रूरी है. सबसे पहले, पुष्टि करें कि आपका ऐप्लिकेशन पब्लिश हो गया है और उसकी पुष्टि हो गई है:

  1. Google Auth Platform खोलें
  2. अपने ऐप्लिकेशन के लिए प्रोजेक्ट चुनें या बनाएं
  3. ऑडियंस पर क्लिक करें और पुष्टि करें कि पब्लिश करने का स्टेटस, पब्लिश किया जा रहा है के तौर पर सेट है
  4. पुष्टि केंद्र पर क्लिक करें और पुष्टि करें कि पुष्टि की स्थिति पुष्टि हो चुकी है के तौर पर सेट है

इसके बाद, अतिरिक्त दावों की सुविधा चालू करें:

  1. मेन्यू में जाकर, सेटिंग पर क्लिक करें
  2. ऐडवांस सेटिंग में जाकर, इनमें से कोई विकल्प चुनें:
    • auth_time को चालू करने के लिए, सेशन की उम्र से जुड़े दावे
    • amr को चालू करने के लिए, पुष्टि करने के बेहतर तरीके से जुड़े दावे

ज़्यादा जानने के लिए, OAuth ऐप्लिकेशन की पुष्टि करने से जुड़े सहायता केंद्र पर जाएं.

इस्तेमाल की जा सकने वाली सुविधाएं

इस सेक्शन में, Security Bundle में शामिल अलग-अलग सुविधाओं के बारे में बताया गया है.

पुष्टि करने के तरीकों के रेफ़रंस

Authentication Methods References (amr) एक OpenID Connect claim है. यह उपयोगकर्ता और Google के बीच, पुष्टि करने के आखिरी इवेंट के दौरान इस्तेमाल किए गए तरीकों के बारे में बताता है.

Google, IANA.AMR की इन वैल्यू के साथ काम करता है. इनसे यह पता चलता है कि:

  • hwk हार्डवेयर सुरक्षा कुंजी का इस्तेमाल किया गया था
  • mfa कई चरणों में पुष्टि करने की प्रोसेस पूरी हो गई है
  • pwd पासवर्ड का इस्तेमाल किया गया
  • swk पासकी जैसी सॉफ़्टवेयर कुंजी का इस्तेमाल किया गया था
  • sms पुष्टि करने के लिए एसएमएस का इस्तेमाल किया गया था
  • tel पुष्टि करने के लिए फ़ोन कॉल का इस्तेमाल किया गया था

इनमें से एक या उससे ज़्यादा वैल्यू, आईडी टोकन amr दावे में स्ट्रिंग के JSON कलेक्शन के तौर पर दिखाई जाती हैं.

amr दावा, आईडी टोकन में सिर्फ़ तब शामिल किया जाता है, जब इस्तेमाल की गई पुष्टि करने की विधि के बारे में जानकारी उपलब्ध हो. अनुरोध किए जाने पर भी यह मौजूद नहीं हो सकता.

Google खाते के मालिक यह तय कर सकते हैं कि दो चरणों में पुष्टि करने की सुविधा चालू करनी है या नहीं. साथ ही, वे यह भी तय कर सकते हैं कि पुष्टि करने के लिए कौनसे तरीके इस्तेमाल करने हैं. किसी Google खाते पर ऐडवांस सुरक्षा चालू होने पर, दो चरणों में पुष्टि करने का मज़बूत तरीका इस्तेमाल करना ज़रूरी होता है. जैसे, Titan Security Key (hwk) या पासकी (swk). इन दोनों स्थितियों में, Google खाते में साइन इन करते समय एक से ज़्यादा फ़ैक्टर का इस्तेमाल करने पर, mfa वैल्यू मौजूद होती है.

mfa की मौजूदगी से यह पुष्टि होती है कि पुष्टि करने वाले इवेंट ने, कई चरणों में पुष्टि करने की सुविधा के लिए Google की ज़रूरी शर्तों को पूरा किया है. उदाहरण के लिए, Google खाते में पासवर्ड (pwd) और पासकी (swk) की मदद से पुष्टि करने पर, यह दावा "amr": ["mfa", "pwd", "swk"] मिलता है.

इन संसाधनों में, खाते की सुरक्षा और उपयोगकर्ता की पुष्टि करने के बारे में ज़्यादा जानकारी दी गई है: Advanced Protection Program की मदद से, Google खाते को सबसे बेहतर तरीके से सुरक्षित रखें, पासवर्ड के बजाय पासकी से साइन इन करें, और दो चरणों में पुष्टि करने के लिए सुरक्षा कुंजी का इस्तेमाल करें.

Workspace के एडमिन, मैनेज किए जा रहे Workspace खातों के लिए पुष्टि करने की नीति को कंट्रोल करते हैं. वे एमएफ़ए या सुरक्षा कुंजियों के इस्तेमाल की ज़रूरत तय कर सकते हैं. ज़्यादा जानकारी के लिए, Google के आइडेंटिटी मैनेजमेंट की खास जानकारी और Google Cloud के लिए मल्टी-फ़ैक्टर ऑथेंटिकेशन की ज़रूरी शर्तें लॉगिन की सुरक्षा और कंट्रोल लेख पढ़ें.

पुष्टि करने का समय

auth_time दावा, OpenID Connect प्रोटोकॉल का एक स्टैंडर्ड हिस्सा है. यह इस बारे में जानकारी देता है कि असली उपयोगकर्ता ने Google के साथ सबसे हाल ही में कब पुष्टि की थी. यह एक JSON नंबर है. यह यूनिक्स इपोक (1 जनवरी, 1970, 00:00:00 यूटीसी) के बाद से अब तक के सेकंड की संख्या को दिखाता है. साथ ही, यह वह समय है जब उपयोगकर्ता ने पिछली बार पुष्टि की थी. इसे टाइमस्टैंप के तौर पर देखा जा सकता है. इससे पता चलता है कि उपयोगकर्ता ने मौजूदा डिवाइस या ब्राउज़र से, अपने Google खाते में आखिरी बार कब लॉग इन किया था. यह दावा, आईडी टोकन में शामिल होता है. यह एक JSON Web Token (JWT) होता है. इसमें पुष्टि करने और उपयोगकर्ता के बारे में पुष्टि की गई जानकारी शामिल होती है.

auth_time दावा आपके ऐप्लिकेशन के लिए अहम है. इसकी मदद से, यह पता लगाया जा सकता है कि उपयोगकर्ता ने जिस डिवाइस या ब्राउज़र का इस्तेमाल किया है उस पर उसने हाल ही में किसी Google खाते में कब लॉग इन किया था. सुरक्षा के लिहाज़ से यह खास तौर पर ज़रूरी हो सकता है. जैसे:

  • यह तय करने में मदद मिलती है कि क्या आपके ऐप्लिकेशन को संवेदनशील उपयोगकर्ता कार्रवाइयां करने से पहले, पुष्टि करने के लिए एक और चरण जोड़ना चाहिए. जैसे, खाता मिटाना, खाते से संपर्क करने के तरीके बदलना या पेमेंट करना. Google, Google खाते की फिर से पुष्टि करने के अनुरोधों का समर्थन नहीं करता है.

  • उपयोगकर्ता के Google खाते के सेशन के नए और स्थिर होने की जानकारी को भरोसेमंद सिग्नल के तौर पर इस्तेमाल करना. आम तौर पर, हाल ही की auth_time वैल्यू से पता चलता है कि सेशन नया है. वहीं, पुरानी वैल्यू से पता चलता है कि सेशन स्थिर है.

वेब ऐप्लिकेशन के लिए, उपयोगकर्ता के ब्राउज़र और ऑपरेटिंग सिस्टम के कॉम्बिनेशन को सेशन माना जाता है. यह तब होता है, जब उपयोगकर्ता अपने Google खाते में साइन इन करता है. आपकी वेबसाइट, उपयोगकर्ता के सेशन को अलग से मैनेज करती है. नई auth_time वैल्यू से पता चलता है कि उपयोगकर्ता ने हाल ही में अपने Google खाते में साइन इन किया है. आम तौर पर, इससे पता चलता है कि उपयोगकर्ता सक्रिय है और ऐप्लिकेशन का इस्तेमाल कर रहा है. इसे कम जोखिम वाले सिग्नल के तौर पर भी देखा जा सकता है.

Android जैसे मोबाइल प्लैटफ़ॉर्म पर, उपयोगकर्ता आम तौर पर सीधे अपने डिवाइस में साइन इन करते हैं. इसके लिए, वे बायोमेट्रिक तरीकों का इस्तेमाल करते हैं. जैसे, फ़िंगरप्रिंट या चेहरे की पहचान. इसके अलावा, वे डिवाइस के हिसाब से पिन या पैटर्न अनलॉक का इस्तेमाल करते हैं. मोबाइल ऐप्लिकेशन और प्लैटफ़ॉर्म, अक्सर Google के साथ नया सेशन बनाने के बजाय, प्लैटफ़ॉर्म पर आधारित पुष्टि करने के इन तरीकों का इस्तेमाल करते हैं. इससे, Google खाते में कम बार साइन इन किया जाता है और auth_time में अपडेट भी कम बार होते हैं. इसलिए, यहां हाल ही की auth_time वैल्यू, लंबे समय से चल रहे Google खाते के सेशन में बदलाव का संकेत दे सकती है. इससे जोखिम बढ़ जाता है.

भरोसेमंद होने के सिग्नल एक जटिल विषय है. auth_time का इस्तेमाल अन्य सिग्नल के साथ किया जाना चाहिए. जैसे, बहु-स्तरीय पुष्टि (एमएफ़ए) चालू है या नहीं, पुष्टि करने के लिए इस्तेमाल किया गया तरीका, और आपके ऐप्लिकेशन और आपके प्लैटफ़ॉर्म के बीच उपयोगकर्ता के सेशन की अवधि.

अनुरोध

auth_time और amr के दावों का अनुरोध करने के लिए इस्तेमाल किया गया तरीका, इस्तेमाल किए गए एपीआई के हिसाब से अलग-अलग होता है. हालांकि, हर एपीआई में auth_time और amr का अनुरोध करने के लिए, एक वैकल्पिक claims पैरामीटर शामिल होता है.

OIDC प्रोटोकॉल

OAuth प्लैटफ़ॉर्म का सीधे तौर पर इस्तेमाल करते समय, auth_time का अनुरोध करें. इसके लिए, इसे claims अनुरोध पैरामीटर में जोड़ें. दावों के JSON ऑब्जेक्ट के id_token फ़ील्ड की वैल्यू को {"auth_time":{"essential":true}} पर सेट करें. इसी तरह, amr का अनुरोध करने के लिए, claims में {"amr":{"essential":true}} जोड़ें:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=id_token&
client_id=YOUR_CLIENT_ID&
scope=openid email profile&
redirect_uri=https://example.com/user-login&
nonce=123-456-7890&
claims={ "id_token": {
            "auth_time": { "essential":true },
            "amr": {"essential":true}
          }
        }

ज़्यादा जानकारी के लिए, OpenID Connect देखें.

वेब के लिए GIS

वेब के लिए Google से साइन इन करें लाइब्रेरी में दो एपीआई होते हैं: एचटीएमएल और JavaScript. इनका इस्तेमाल अतिरिक्त दावों का अनुरोध करने के लिए किया जाता है. उदाहरण के लिए, JavaScript API का इस्तेमाल करके auth_time और amr का अनुरोध करें:

<html>
<body>
  <script src="https://accounts.google.com/gsi/client" async></script>
  <script>
    window.onload = function () {
      google.accounts.id.initialize({
        client_id: "YOUR_WEB_CLIENT_ID",
        callback: function(rsp) { console.log(rsp.credential); },
        essential_claims: "auth_time, amr",
      });
      google.accounts.id.renderButton(
        document.getElementById("buttonDiv"),
        { type: "standard", size: "large" }
      );
    }
  </script>
  <div id="buttonDiv"></div>
</body>
</html>

ज़्यादा जानकारी के लिए, वेब के लिए 'Google से साइन इन करें' देखें.

Android के लिए GIS

auth_time और amr का अनुरोध करने के लिए, setClaims तरीके और Claim ऑब्जेक्ट का इस्तेमाल किया जाता है.

androidx.credentials:credentials-play-services-auth और com.google.android.libraries.identity.googleid:googleid लाइब्रेरी के सबसे नए वर्शन इस्तेमाल करने के लिए, अपनी बिल्ड डिपेंडेंसी अपडेट करें.

साइन-इन करने के विकल्पों की सूची में जोड़ने के लिए, setClaims का इस्तेमाल करके auth_time और amr टाइप के Claim ऑब्जेक्ट इंस्टैंशिएट करें:

val googleIdOption: GetGoogleIdOption = GetGoogleIdOption.Builder()
    .setAutoSelectEnabled(true)
    .setFilterByAuthorizedAccounts(true)
    .setServerClientId(WEB_CLIENT_ID)
    .setNonce("NONCE")
    .setClaims(ImmutableList.of(
           new Claim("auth_time", true),
           new Claim("amr", true)
    ))
    .build()

ज़्यादा जानकारी के लिए, 'Google से साइन इन करें' सुविधा का इस्तेमाल करके उपयोगकर्ताओं की पुष्टि करना लेख पढ़ें.

iOS

iOS के लिए Google से साइन इन करें SDK, GIDSignIn क्लास में authTimeClaim ऑब्जेक्ट और claims पैरामीटर जोड़ता है. इसका इस्तेमाल, auth_time और amr का अनुरोध करने के लिए किया जाता है.

ASWebAuthenticationSession का इस्तेमाल करने वाले ऐप्लिकेशन, डिवाइस-वाइड शेयर किए गए कुकी जार को अपडेट करते हैं. GIDSignIn इस तरीके का इस्तेमाल डिफ़ॉल्ट रूप से iOS 12 या इसके बाद के वर्शन और macOS 10.15 या इसके बाद के वर्शन में करता है. इस स्थिति में, अपने Google खाते में साइन इन करने वाले उपयोगकर्ता की पुष्टि की जाती है. साथ ही, सेशन को शेयर किए गए कुकी जार में सेव किया जाता है. यहां auth_time, डिवाइस पर उपयोगकर्ता की आखिरी Google पुष्टि है. यह सिर्फ़ आपके ऐप्लिकेशन में नहीं है.

SFSafariViewController, WKWebView, और UIWebView, आपके ऐप्लिकेशन में अलग-अलग सैंडबॉक्स में काम करते हैं. auth_time का इस्तेमाल करते समय, इनका इस्तेमाल न करें. यहां auth_time का मतलब है कि उपयोगकर्ता ने आखिरी बार ऐप्लिकेशन में साइन इन कब किया था. इसकी वैल्यू हमेशा हाल की होती है, इसलिए यह ज़्यादा काम की नहीं होती.

auth_time का अनुरोध करने के लिए, GoogleSignIn dependencies को नए वर्शन में अपडेट करें. इसके बाद, authTimeClaim ऑब्जेक्ट बनाएं और उसे claims सेट में जोड़ें.

amr से amrClaim ऑब्जेक्ट बनाने और उसे claims सेट में जोड़ने का अनुरोध करने के लिए.

Swift

सेट किए गए दावों को GIDSignIn.sharedInstance.signIn तरीके में जोड़ें:

let authTimeClaim = GIDClaim.authTime()
let amrClaim = GIDClaim.amr()
let claims = Set([authTimeClaim, amrClaim])

// Start the sign-in process GIDSignIn.sharedInstance.signIn( withPresenting: rootViewController, claims: claims ) { signInResult, error in guard let result = signInResult else { print("Error signing in: (error?.localizedDescription ?? "No error description")") return } // If sign in succeeded, display the app's main content View print("ID Token: (result.user.idToken?.tokenString ?? "No token")") }

Objective-C

सेट किए गए दावों को signInWithPresentingViewController तरीके में जोड़ें:

GIDClaim *authTimeClaim = [GIDClaim authTimeClaim];
GIDClaim *AMRClaim = [GIDClaim AMRClaim];
NSSet *claims = [NSSet setWithArray:@[authTimeClaim, AMRClaim]];

// Include the claims set and start the sign-in process [GIDSignIn.sharedInstance signInWithPresentingViewController:self hint:nil claims:claims completion:^(GIDSignInResult * _Nullable signInResult, NSError * _Nullable error) { // On success signInResult.user.idToken // contains the requested claims. }];

ज़्यादा जानकारी के लिए, अपने iOS या macOS ऐप्लिकेशन में 'Google साइन इन' को इंटिग्रेट करना लेख पढ़ें.

जवाब

अनुरोध में auth_time या amr दावे शामिल होने पर, उन्हें आईडी टोकन के पेलोड रिस्पॉन्स में दिखाया जाता है. साथ ही, iss (जारी करने वाला), sub (विषय), aud (दर्शक), और exp (समयसीमा खत्म होने का समय) जैसे अन्य स्टैंडर्ड दावे भी दिखाए जाते हैं.

दावों के न दिखने की वजह यह हो सकती है कि ऐप्लिकेशन की पुष्टि नहीं हुई है या अतिरिक्त सेटिंग बंद हैं. ये सेटिंग डिफ़ॉल्ट रूप से बंद रहती हैं. सेटअप में दिए गए निर्देशों का पालन करके, यह पुष्टि करें कि इस्तेमाल किया जा रहा Client-ID और ऐप्लिकेशन, पुष्टि किए गए हैं. साथ ही, अतिरिक्त दावे चालू किए गए हैं.

auth_time दावे की वैल्यू, JSON नंबर होती है. यह Unix epoch (1 जनवरी, 1970, 00:00:00 UTC) से लेकर उपयोगकर्ता की पुष्टि होने के समय तक के सेकंड की संख्या को दिखाती है.

amr दावे की वैल्यू, स्ट्रिंग का JSON कलेक्शन होती है. यह कलेक्शन, Google खाते में आखिरी बार साइन इन करने के दौरान इस्तेमाल किए गए पुष्टि करने के तरीकों को दिखाता है.

यह डिकोड किए गए आईडी टोकन का उदाहरण है. इसमें auth_time और amr दावे शामिल हैं:

{
  "iss": "https://accounts.google.com",
  "azp": "YOUR_CLIENT_ID",
  "aud": "YOUR_CLIENT_ID",
  "sub": "117726431651943698600",
  "email": "alice@example.com",
  "email_verified": true,
  "nonce": "123-456-7890",
  "auth_time": 1748875426,
  "amr": ["mfa", "pwd", "tel"],
  "nbf": 1748880889,
  "name": "Elisa Beckett",
  "picture": "https://lh3.googleusercontent.com/a/default-user=s96-c",
  "given_name": "Elisa",
  "family_name": "Beckett",
  "iat": 1748881189,
  "exp": 1748884789,
  "jti": "8b5d7ce345787d5dbf14ce6e08a8f88ee8c9b5b1"
}

आईडी टोकन में iat (जारी किए जाने का समय) दावा भी शामिल होता है. इससे पता चलता है कि JWT कब जारी किया गया था. iat और auth_time दावों की तुलना करके, यह पता लगाया जा सकता है कि उपयोगकर्ता के आखिरी बार पुष्टि किए जाने के बाद से कितना समय बीत चुका है. यह समय, किसी खास आईडी टोकन के बनाए जाने के समय के हिसाब से तय किया जाता है. उदाहरण के लिए, अगर iat 1748881189 है और auth_time 1748875426 है, तो दोनों के बीच का अंतर 5763 सेकंड है. इसका मतलब है कि 1 घंटे, 36 मिनट, और 3 सेकंड बीत चुके हैं.