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

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

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

अगर आपके ऐप्लिकेशन में ऐसी सुविधाएं हैं जो Google API के डेटा का इस्तेमाल कर सकती हैं, लेकिन ये आपके ऐप्लिकेशन की मुख्य सुविधाओं का हिस्सा नहीं हैं, तो अपने ऐप्लिकेशन को इस तरह डिज़ाइन करें कि 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 फ़ाइल में मौजूद <manifest> एलिमेंट के package एट्रिब्यूट में तय की जाती है.
    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 डेवलपर खाता हो और आपका ऐप्लिकेशन, 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:21.5.1"
}

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

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

Kotlin

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) }

Java

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

Kotlin

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
            }
        }
}

Java

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 को ऐक्सेस किया जा रहा है, तो ऑथराइज़ेशन कोड पाने के लिए, getServerAuthCode() तरीके को AuthorizationResult से कॉल करें. इसके बाद, इस कोड को अपने बैकएंड पर भेजें, ताकि इसे ऐक्सेस और रीफ़्रेश टोकन के लिए एक्सचेंज किया जा सके. ज़्यादा जानने के लिए, उपयोगकर्ता के डेटा का ऐक्सेस जारी रखना देखें.

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

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

Kotlin

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) }

Java

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 को हटाता है:

Kotlin

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) }

Java

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 को ऐक्सेस करने के लिए ऐक्सेस टोकन पाने के रिस्पॉन्स में, उस खाते की पहचान का पता नहीं चलता जिसे उपयोगकर्ता ने चुना था. भले ही, इसका इस्तेमाल उपयोगकर्ता के Drive पर मौजूद फ़ाइलों को ऐक्सेस करने के लिए किया जा सकता हो. उपयोगकर्ता का नाम या ईमेल जैसी जानकारी पाने के लिए, आपके पास ये विकल्प हैं:

  • ऑथराइज़ेशन का अनुरोध करने से पहले, Credential Manager API का इस्तेमाल करके, उपयोगकर्ता को उसके Google खाते से साइन इन कराएं. 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() API का इस्तेमाल करके, उपयोगकर्ता को ऐप्लिकेशन से साइन आउट करें.

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

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

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

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

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

Kotlin

// 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) }

Java

// 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"));

यहां दिए गए स्निपेट में, यह मान लिया गया है कि ऑथराइज़ेशन, किसी फ़्रैगमेंट से शुरू किया गया है.

Kotlin

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
            }
        }
}

Java

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
                }
            });
}