Google उपयोगकर्ता के डेटा को ऐक्सेस करने की अनुमति देना

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

ऐप्लिकेशन की ज़रूरतों के हिसाब से, पुष्टि करने और अनुमति देने के कॉल, दो अलग-अलग फ़्लो होने चाहिए.

अगर आपके ऐप्लिकेशन में ऐसी सुविधाएं हैं जो Google API के डेटा का इस्तेमाल कर सकती हैं, लेकिन वे आपके ऐप्लिकेशन की मुख्य सुविधाओं के तौर पर ज़रूरी नहीं हैं, तो अपने ऐप्लिकेशन को इस तरह डिज़ाइन करें कि वह एपीआई डेटा को ऐक्सेस न कर पाने की स्थिति को आसानी से मैनेज कर सके. उदाहरण के लिए, अगर उपयोगकर्ता ने Drive को ऐक्सेस करने की अनुमति नहीं दी है, तो हाल ही में सेव की गई फ़ाइलों की सूची को छिपाया जा सकता है.

आपको Google API को ऐक्सेस करने के लिए ज़रूरी स्कोप के ऐक्सेस का अनुरोध सिर्फ़ तब करना चाहिए, जब उपयोगकर्ता कोई ऐसी कार्रवाई करे जिसके लिए किसी खास एपीआई के ऐक्सेस की ज़रूरत हो. उदाहरण के लिए, जब भी उपयोगकर्ता Drive में सेव करें बटन पर टैप करे, तब आपको उपयोगकर्ता की Drive को ऐक्सेस करने की अनुमति का अनुरोध करना चाहिए.

अनुमति देने और पुष्टि करने की प्रोसेस को अलग-अलग रखकर, नए उपयोगकर्ताओं को भ्रमित होने से बचाया जा सकता है. साथ ही, उपयोगकर्ताओं को यह समझने में मदद मिलती है कि उनसे कुछ अनुमतियां क्यों मांगी जा रही हैं.

पुष्टि करने के लिए, हमारा सुझाव है कि आप Credential Manager API का इस्तेमाल करें. Google के पास सेव किए गए उपयोगकर्ता के डेटा को ऐक्सेस करने के लिए, हम AuthorizationClient का इस्तेमाल करने का सुझाव देते हैं.

Google Cloud Console प्रोजेक्ट सेट अप करना

1. Cloud Console में अपना प्रोजेक्ट खोलें. अगर आपके पास कोई प्रोजेक्ट नहीं है, तो एक प्रोजेक्ट बनाएं.
2. ब्रैंडिंग पेज पर, पक्का करें कि सारी जानकारी पूरी और सही हो.
   1. पक्का करें कि आपके ऐप्लिकेशन का नाम, लोगो, और होम पेज सही हो. ये वैल्यू, उपयोगकर्ताओं को साइन अप करते समय, 'Google से साइन इन करें' सुविधा के लिए सहमति देने वाली स्क्रीन और तीसरे पक्ष के ऐप्लिकेशन और सेवाओं वाली स्क्रीन पर दिखेंगी.
   2. पक्का करें कि आपने अपने ऐप्लिकेशन की निजता नीति और सेवा की शर्तों के यूआरएल दिए हों.
3. क्लाइंट पेज पर, अपने ऐप्लिकेशन के लिए Android क्लाइंट आईडी बनाएं. ऐसा तब करें, जब आपके पास पहले से कोई आईडी न हो. आपको अपने ऐप्लिकेशन के पैकेज का नाम और SHA-1 सिग्नेचर बताना होगा.
   1. क्लाइंट पेज पर जाएं.
   2. क्लाइंट बनाएं पर क्लिक करें.
   3. Android ऐप्लिकेशन टाइप चुनें.
   4. OAuth क्लाइंट के लिए कोई नाम डालें. यह नाम आपके प्रोजेक्ट के क्लाइंट पेज पर दिखता है, ताकि क्लाइंट की पहचान की जा सके.
   5. अपने Android ऐप्लिकेशन के पैकेज का नाम डालें. यह वैल्यू, आपकी AndroidManifest.xml फ़ाइल में मौजूद package एट्रिब्यूट के <manifest> एलिमेंट में तय की जाती है.
   6. ऐप्लिकेशन डिस्ट्रिब्यूशन के SHA-1 साइनिंग सर्टिफ़िकेट का फ़िंगरप्रिंट डालें.
   7. अगर आपका ऐप्लिकेशन Google Play की ऐप्लिकेशन साइनिंग सुविधा का इस्तेमाल करता है, तो Play Console के ऐप्लिकेशन साइनिंग पेज से SHA-1 फ़िंगरप्रिंट कॉपी करें.
   8. अगर आपको अपना कीस्टोर और साइनिंग पासकोड खुद मैनेज करना है, तो Java में शामिल keytool यूटिलिटी का इस्तेमाल करें. इससे सर्टिफ़िकेट की जानकारी को किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाले डेटा फ़ॉर्मैट में प्रिंट किया जा सकता है. keytool आउटपुट के Certificate fingerprints सेक्शन में मौजूद SHA-1 वैल्यू को कॉपी करें. ज़्यादा जानकारी के लिए, Android के लिए Google API के दस्तावेज़ में, अपने क्लाइंट की पुष्टि करना देखें.
   9. (ज़रूरी नहीं) अपने Android ऐप्लिकेशन के मालिकाना हक की पुष्टि करें.
4. क्लाइंट पेज पर, नया "वेब ऐप्लिकेशन" क्लाइंट आईडी बनाएं. ऐसा तब करें, जब आपने पहले से कोई क्लाइंट आईडी न बनाया हो. फ़िलहाल, "अनुमति वाले JavaScript ऑरिजिन" और "अनुमति वाले रीडायरेक्ट यूआरआई" फ़ील्ड को अनदेखा किया जा सकता है. इस क्लाइंट आईडी का इस्तेमाल, आपके बैकएंड सर्वर की पहचान करने के लिए किया जाएगा. ऐसा तब होगा, जब यह Google की पुष्टि करने वाली सेवाओं के साथ कम्यूनिकेट करेगा.
   1. क्लाइंट पेज पर जाएं.
   2. क्लाइंट बनाएं पर क्लिक करें.
   3. वेब ऐप्लिकेशन टाइप चुनें.

ऐप्लिकेशन के मालिकाना हक की पुष्टि करना

अपने ऐप्लिकेशन के मालिकाना हक की पुष्टि की जा सकती है, ताकि कोई दूसरा व्यक्ति आपके ऐप्लिकेशन के नाम पर धोखाधड़ी न कर सके.

पुष्टि की प्रक्रिया पूरी करने के लिए, Google Play डेवलपर खाते का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि आपके पास यह खाता हो और आपका ऐप्लिकेशन Google Play Console पर रजिस्टर हो. पुष्टि की प्रक्रिया पूरी करने के लिए, ये ज़रूरी शर्तें पूरी करनी होंगी:

• आपके पास Google Play Console में रजिस्टर किया गया एक ऐसा ऐप्लिकेशन होना चाहिए जिसका पैकेज नाम और SHA-1 साइनिंग सर्टिफ़िकेट फ़िंगरप्रिंट, Android OAuth क्लाइंट के जैसा हो. यह वही क्लाइंट होना चाहिए जिसकी पुष्टि की जा रही है.
• आपके पास Google Play Console में ऐप्लिकेशन के लिए, एडमिन के तौर पर मिली अनुमति होनी चाहिए. Google Play Console में ऐक्सेस मैनेजमेंट के बारे में ज़्यादा जानें.

Android क्लाइंट के ऐप्लिकेशन के मालिकाना हक की पुष्टि करें सेक्शन में, मालिकाना हक की पुष्टि करें बटन पर क्लिक करें. इससे पुष्टि की प्रक्रिया पूरी हो जाएगी.

पुष्टि की प्रक्रिया पूरी होने पर, आपको इसकी सूचना मिलेगी. ऐसा न करने पर, गड़बड़ी का प्रॉम्प्ट दिखेगा.

पुष्टि न होने की समस्या को हल करने के लिए, यह तरीका अपनाएं:

• पक्का करें कि जिस ऐप्लिकेशन की पुष्टि की जा रही है वह Google Play Console में रजिस्टर किया गया हो.
• पक्का करें कि आपके पास Google Play Console में, ऐप्लिकेशन के लिए एडमिन के तौर पर मिली अनुमति हो.

डिपेंडेंसी का एलान करना

अपने मॉड्यूल की build.gradle फ़ाइल में, Google Identity Services लाइब्रेरी के नए वर्शन का इस्तेमाल करके डिपेंडेंसी का एलान करें.

dependencies {
  // ... other dependencies

  implementation "com.google.android.gms:play-services-auth:22.0.0"
}

उपयोगकर्ता की कार्रवाइयों के लिए ज़रूरी अनुमतियों का अनुरोध करना

जब भी कोई उपयोगकर्ता ऐसी कार्रवाई करता है जिसके लिए अतिरिक्त स्कोप की ज़रूरत होती है, तो AuthorizationClient.authorize() को कॉल करें. उदाहरण के लिए, अगर कोई उपयोगकर्ता ऐसी कार्रवाई करता है जिसके लिए उसके Drive ऐप्लिकेशन के स्टोरेज का ऐक्सेस ज़रूरी है, तो ये काम करें:

val requestedScopes: List<Scope> = listOf(DriveScopes.DRIVE_FILE)
val authorizationRequest = AuthorizationRequest.builder()
    .setRequestedScopes(requestedScopes)
    .build()

Identity.getAuthorizationClient(activity)
    .authorize(authorizationRequestBuilder.build())
    .addOnSuccessListener { authorizationResult ->
        if (authorizationResult.hasResolution()) {
            val pendingIntent = authorizationResult.pendingIntent
            // Access needs to be granted by the user
            startAuthorizationIntent.launch(IntentSenderRequest.Builder(pendingIntent!!.intentSender).build())
        } else {
            // Access was previously granted, continue with user action
            saveToDriveAppFolder(authorizationResult);
        }
    }
    .addOnFailureListener { e -> Log.e(TAG, "Failed to authorize", e) }

List<Scopes> requestedScopes = Arrays.asList(DriveScopes.DRIVE_FILE);
AuthorizationRequest authorizationRequest = AuthorizationRequest.builder()
    .setRequestedScopes(requestedScopes)
    .build();

Identity.getAuthorizationClient(activity)
    .authorize(authorizationRequest)
    .addOnSuccessListener(authorizationResult -> {
        if (authorizationResult.hasResolution()) {
            // Access needs to be granted by the user
            startAuthorizationIntent.launch(
                new IntentSenderRequest.Builder(
                    authorizationResult.getPendingIntent().getIntentSender()
                ).build()
            );
        } else {
            // Access was previously granted, continue with user action
            saveToDriveAppFolder(authorizationResult);
        }
    })
    .addOnFailureListener(e -> Log.e(TAG, "Failed to authorize", e));

ActivityResultLauncher को तय करते समय, रिस्पॉन्स को इस स्निपेट में दिखाए गए तरीके से हैंडल करें. यहां हम मान लेते हैं कि यह फ़्रैगमेंट में किया गया है. कोड यह जांच करता है कि ज़रूरी अनुमतियां दी गई हैं या नहीं. इसके बाद, उपयोगकर्ता की कार्रवाई को पूरा करता है.

private lateinit var startAuthorizationIntent: ActivityResultLauncher<IntentSenderRequest>

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?,
): View? {
    // ...
    startAuthorizationIntent =
        registerForActivityResult(ActivityResultContracts.StartIntentSenderForResult()) { activityResult ->
            try {
                // extract the result
                val authorizationResult = Identity.getAuthorizationClient(requireContext())
                    .getAuthorizationResultFromIntent(activityResult.data)
                // continue with user action
                saveToDriveAppFolder(authorizationResult);
            } catch (e: ApiException) {
                // log exception
            }
        }
}

private ActivityResultLauncher<IntentSenderRequest> startAuthorizationIntent;

@Override
public View onCreateView(
    @NonNull LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
// ...
startAuthorizationIntent =
    registerForActivityResult(
        new ActivityResultContracts.StartIntentSenderForResult(),
        activityResult -> {
            try {
            // extract the result
            AuthorizationResult authorizationResult =
                Identity.getAuthorizationClient(requireActivity())
                    .getAuthorizationResultFromIntent(activityResult.getData());
            // continue with user action
            saveToDriveAppFolder(authorizationResult);
            } catch (ApiException e) {
            // log exception
            }
        });
}

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

उपयोगकर्ता के डेटा या संसाधनों का ऐक्सेस वापस लेना

पहले दिए गए ऐक्सेस को वापस लेने के लिए, AuthorizationClient.revokeAccess() को कॉल करें. उदाहरण के लिए, अगर कोई उपयोगकर्ता आपके ऐप्लिकेशन से अपना खाता हटा रहा है और आपके ऐप्लिकेशन को पहले DriveScopes.DRIVE_FILE का ऐक्सेस दिया गया था, तो ऐक्सेस वापस लेने के लिए इस कोड का इस्तेमाल करें:

val requestedScopes: MutableList<Scope> = mutableListOf(DriveScopes.DRIVE_FILE)
RevokeAccessRequest revokeAccessRequest = RevokeAccessRequest.builder()
    .setAccount(account)
    .setScopes(requestedScopes)
    .build()

Identity.getAuthorizationClient(activity)
    .revokeAccess(revokeAccessRequest)
    .addOnSuccessListener { Log.i(TAG, "Successfully revoked access") }
    .addOnFailureListener { e -> Log.e(TAG, "Failed to revoke access", e) }

List<Scopes> requestedScopes = Arrays.asList(DriveScopes.DRIVE_FILE);
RevokeAccessRequest revokeAccessRequest = RevokeAccessRequest.builder()
    .setAccount(account)
    .setScopes(requestedScopes)
    .build();

Identity.getAuthorizationClient(activity)
    .revokeAccess(revokeAccessRequest)
    .addOnSuccessListener(unused -> Log.i(TAG, "Successfully revoked access"))
    .addOnFailureListener(e -> Log.e(TAG, "Failed to revoke access", e));

टोकन की कैश मेमोरी मिटाना

सर्वर से मिलने पर, OAuth ऐक्सेस टोकन को स्थानीय तौर पर कैश मेमोरी में सेव किया जाता है. इससे ऐक्सेस की स्पीड बढ़ती है और नेटवर्क कॉल कम होते हैं. समयसीमा खत्म होने पर, ये टोकन कैश मेमोरी से अपने-आप मिट जाते हैं. हालांकि, ये अन्य वजहों से भी अमान्य हो सकते हैं. अगर आपको टोकन का इस्तेमाल करते समय IllegalStateException मिलता है, तो लोकल कैश मेमोरी को मिटाएं. इससे यह पक्का किया जा सकेगा कि ऐक्सेस टोकन के लिए, अनुमति का अगला अनुरोध OAuth सर्वर पर जाए. नीचे दिया गया स्निपेट, लोकल कैश मेमोरी से invalidAccessToken को हटा देता है:

Identity.getAuthorizationClient(activity)
    .clearToken(ClearTokenRequest.builder().setToken(invalidAccessToken).build())
    .addOnSuccessListener { Log.i(TAG, "Successfully removed the token from the cache") }
    .addOnFailureListener{ e -> Log.e(TAG, "Failed to clear token", e) }

Identity.getAuthorizationClient(activity)
    .clearToken(ClearTokenRequest.builder().setToken(invalidAccessToken).build())
    .addOnSuccessListener(unused -> Log.i(TAG, "Successfully removed the token from the cache"))
    .addOnFailureListener(e -> Log.e(TAG, "Failed to clear the token cache", e));

अनुमति देने के दौरान उपयोगकर्ता की जानकारी पाना

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

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

• अनुमति के अनुरोध में, अपनी पसंद के स्कोप (उदाहरण के लिए, Drive scope) के अलावा, userinfo, profile, और openid स्कोप के लिए भी अनुरोध करें. ऐक्सेस टोकन मिलने के बाद, उपयोगकर्ता की जानकारी पाने के लिए, अपनी पसंदीदा एचटीटीपी लाइब्रेरी का इस्तेमाल करके, OAuth userinfo एंडपॉइंट (https://www.googleapis.com/oauth2/v3/userinfo) पर GET एचटीटीपी अनुरोध करें. साथ ही, हेडर में वह ऐक्सेस टोकन शामिल करें जो आपको मिला था. यह टोकन, इस curl कमांड के बराबर है:

  curl -X GET \ "https://www.googleapis.com/oauth2/v1/userinfo?alt=json" \ -H "Authorization: Bearer $TOKEN"
  

  रिस्पॉन्स, UserInfo होता है. यह उन स्कोप तक सीमित होता है जिनके लिए अनुरोध किया गया था. साथ ही, इसे JSON में फ़ॉर्मैट किया जाता है.

डिफ़ॉल्ट खाते के अलावा किसी अन्य खाते से अनुमति लेना

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

उपयोगकर्ता के डेटा का ऐक्सेस बनाए रखना

अगर आपको अपने ऐप्लिकेशन से उपयोगकर्ता का डेटा ऐक्सेस करना है, तो AuthorizationClient.authorize() को एक बार कॉल करें. इसके बाद के सेशन में और जब तक उपयोगकर्ता, दी गई अनुमतियों को नहीं हटाता, तब तक अपने मकसद को पूरा करने के लिए ऐक्सेस टोकन पाने के लिए, इसी तरीके को कॉल करें. इसके लिए, उपयोगकर्ता को कोई इंटरैक्शन नहीं करना होगा. अगर आपको अपने बैकएंड सर्वर से, ऑफ़लाइन मोड में उपयोगकर्ता का डेटा ऐक्सेस करना है, तो आपको "रीफ़्रेश टोकन" नाम के एक अलग तरह के टोकन का अनुरोध करना होगा.

ऐक्सेस टोकन को जान-बूझकर कम समय के लिए बनाया गया है. इनकी समयसीमा एक घंटे की होती है. अगर किसी ऐक्सेस टोकन को इंटरसेप्ट किया जाता है या उससे छेड़छाड़ की जाती है, तो उसकी सीमित वैधता अवधि की वजह से, उसके गलत इस्तेमाल की संभावना कम हो जाती है. समयसीमा खत्म होने के बाद, टोकन अमान्य हो जाता है. इसके बाद, इसका इस्तेमाल करने की कोशिश करने पर, रिसॉर्स सर्वर इसे अस्वीकार कर देगा. ऐक्सेस टोकन कम समय के लिए होते हैं. इसलिए, सर्वर रीफ़्रेश टोकन का इस्तेमाल करते हैं, ताकि उपयोगकर्ता के डेटा का ऐक्सेस लगातार बना रहे. रीफ़्रेश टोकन, लंबे समय तक इस्तेमाल किए जा सकने वाले टोकन होते हैं. इनका इस्तेमाल क्लाइंट, ऑथराइज़ेशन सर्वर से कम समय के लिए ऐक्सेस टोकन का अनुरोध करने के लिए करता है. ऐसा तब होता है, जब पुराना ऐक्सेस टोकन खत्म हो जाता है. इसके लिए, उपयोगकर्ता को कुछ करने की ज़रूरत नहीं होती.

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

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

// Ask for offline access during the first authorization request
val authorizationRequest = AuthorizationRequest.builder()
    .setRequestedScopes(requestedScopes)
    .requestOfflineAccess(serverClientId)
    .build()

Identity.getAuthorizationClient(activity)
    .authorize(authorizationRequest)
    .addOnSuccessListener { authorizationResult ->
        startAuthorizationIntent.launch(IntentSenderRequest.Builder(
            pendingIntent!!.intentSender
        ).build())
    }
    .addOnFailureListener { e -> Log.e(TAG, "Failed to authorize", e) }

// Ask for offline access during the first authorization request
AuthorizationRequest authorizationRequest = AuthorizationRequest.builder()
    .setRequestedScopes(requestedScopes)
    .requestOfflineAccess(serverClientId)
    .build();

Identity.getAuthorizationClient(getContext())
    .authorize(authorizationRequest)
    .addOnSuccessListener(authorizationResult -> {
        startAuthorizationIntent.launch(
            new IntentSenderRequest.Builder(
                authorizationResult.getPendingIntent().getIntentSender()
            ).build()
        );
    })
    .addOnFailureListener(e -> Log.e(TAG, "Failed to authorize"));

यहां दिए गए स्निपेट में यह माना गया है कि अनुमति देने की प्रोसेस, फ़्रैगमेंट से शुरू की गई है.

private lateinit var startAuthorizationIntent: ActivityResultLauncher<IntentSenderRequest>

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?,
): View? {
    // ...
    startAuthorizationIntent =
        registerForActivityResult(ActivityResultContracts.StartIntentSenderForResult()) { activityResult ->
            try {
                val authorizationResult = Identity.getAuthorizationClient(requireContext())
                    .getAuthorizationResultFromIntent(activityResult.data)
                // short-lived access token
                accessToken = authorizationResult.accessToken
                // store the authorization code used for getting a refresh token safely to your app's backend server
                val authCode: String = authorizationResult.serverAuthCode
                storeAuthCodeSafely(authCode)
            } catch (e: ApiException) {
                // log exception
            }
        }
}

private ActivityResultLauncher<IntentSenderRequest> startAuthorizationIntent;

@Override
public View onCreateView(
    @NonNull LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    // ...
    startAuthorizationIntent =
        registerForActivityResult(
            new ActivityResultContracts.StartIntentSenderForResult(),
            activityResult -> {
                try {
                    AuthorizationResult authorizationResult =
                        Identity.getAuthorizationClient(requireActivity())
                            .getAuthorizationResultFromIntent(activityResult.getData());
                    // short-lived access token
                    accessToken = authorizationResult.getAccessToken();
                    // store the authorization code used for getting a refresh token safely to your app's backend server
                    String authCode = authorizationResult.getServerAuthCode()
                    storeAuthCodeSafely(authCode);
                } catch (ApiException e) {
                    // log exception
                }
            });
}