Configuration de Google Login

Introduction

Dans ce guide, vous allez apprendre à configurer Google Login avec Capgo Social Login. Voici ce dont vous avez besoin pour configurer Google Login :

• Un compte Google

Configuration générale

Remarque

Cette étape est nécessaire, quelle que soit la plateforme que vous utilisez.

Dans cette partie, vous allez configurer l'écran de connexion affiché par Google.

1. Veuillez vous rendre sur console.cloud.google.com
2. Cliquez sur le sélecteur de projet
3. Si vous n'avez pas encore de projet, veuillez créer un nouveau projet.
   1. Cliquez sur New project
   2. Nommez votre projet et cliquez sur Create
   3. Assurez-vous d'être sur le bon projet
4. Commencez à configurer le OAuth consent screen

   1. Cliquez sur la barre de recherche

      

   2. Recherchez OAuth consent screen et cliquez dessus

      

   3. Configurer l'écran de consentement

      Remarque

      Je pars du principe que vous développez une application ouverte au public ; j'utiliserai donc le external type d'utilisateur. Sélectionnez le type d'utilisateur qui vous convient le mieux ET cliquez sur create

      Cliquez sur create

      
5. Renseigner les informations sur votre application

   1. Commençons par la section App Information

      
      • Veuillez saisir votre App Name

        Attention

        CECI SERA AFFICHÉ AUX UTILISATEURS

      • Saisissez le user support email

        Remarque

        Vous pouvez en savoir plus sur l'e-mail de support ici

      2. Vous PEUT ajouter le logo de l'app.

         

         Remarque

         Ce n'est pas obligatoire et je vais sauter cette étape

      3. Vous DEVRAIT configurer la App domain

         

         Remarque

         Je ne le ferai pas car il s'agit d'une simple démonstration qui sera PAS publiée, mais je recommande vivement de remplir cette section.

      4. Vous À faire fournir l’e-mail du développeur

         

      5. Cliquez sur save and continue

         
6. Configurer les scopes

   1. Cliquez sur add or remove scopes

      

   2. Sélectionnez les scopes suivants et cliquez sur update

      

   3. Cliquez save and continue

      
7. Ajouter un utilisateur de test
   1. Cliquez sur add users
   2. Saisissez votre e-mail Google, appuyez sur Entrée, puis cliquez sur add
   3. Cliquez save and continue
8. Cliquez back to dashboard
9. Soumettre votre application pour vérification

   Remarque

   Je recommande vivement de soumettre votre application pour vérification. Cela sort du cadre de ce tutoriel. Vous pouvez en savoir plus ici. Ce n'est pas nécessaire pour les tests locaux, mais c'est requis pour la production.

Différences entre l'accès en ligne et l'accès hors ligne

Il existe plusieurs façons d'utiliser Google Login avec Capacitor. Voici un tableau qui résume les différences entre les deux :

	Accès en ligne	Accès hors ligne
Nécessite un backend	❌	✅
Token d'accès longue durée	❌	✅
Easy setup	✅	❌

Remarque

Mode hors ligne signifie que votre backend peut accéder aux API Google même lorsque l’utilisateur n’utilise pas activement votre application (c’est-à-dire lorsqu’il est « hors ligne » du point de vue de votre application). Les tokens d’accès à longue durée permettent cette fonctionnalité en autorisant le backend à appeler les API Google au nom de l’utilisateur à tout moment.

Attention

Le mode hors ligne nécessite un serveur backend. Lors de l’utilisation du mode hors ligne, le frontend reçoit un minimum d’informations (principalement un code d’authentification serveur). Sans backend pour échanger ce code contre des tokens et des informations utilisateur, le mode hors ligne ne fournit aucune donnée utile à votre application frontend.

Attention

SocialLogin.refresh({ provider: 'google' }) fait pas travailler avec google.mode: 'offline'. En mode hors ligne, le plugin ne vous fournit que serverAuthCode, et votre backend doit échanger ce code contre des access tokens et des refresh tokens, puis rafraîchir ces tokens côté backend.

Si vous ne savez toujours pas lequel choisir, voici quelques scénarios à considérer :

1. Vous voulez que l'utilisateur se connecte, puis vous lui délivrerez immédiatement un JWT personnalisé. Votre application n'appellera PAS les API Google

   Dans ce cas, choisissez l'accès en ligne.

2. Votre application appellera certaines API Google depuis le client, mais jamais depuis le backend

   Dans ce cas, choisissez l'accès en ligne

3. Votre application appellera certaines API Google depuis le backend, mais uniquement quand l'utilisateur utilise activement l'application

   Dans ce cas, choisissez l'accès en ligne

4. Votre application vérifiera périodiquement le calendrier de l'utilisateur, même lorsque celui-ci n'utilise pas activement l'application

   Dans ce cas, choisissez l'accès hors ligne.

Exemple de backend pour l'accès en ligne

Dans cette partie du tutoriel, je vais vous montrer comment valider l'utilisateur sur votre backend.

Cet exemple est très simple et repose sur les technologies suivantes :

• TypeScript

• Hono

• Le fetch de JavaScript API

Vous pouvez trouver le code pour cet exemple ici

Comme vous pouvez le voir :

L'idée est assez simple. Vous envoyez une simple GET requête à https://www.googleapis.com/oauth2/v3/tokeninfo cela vous indique si le token est valide ou non et, si c'est le cas, vous renvoie l'e-mail de l'utilisateur. Cela fournit également d'autres informations sur le token de l'utilisateur

À partir de là, vous pouvez délivrer votre propre JWT à l'utilisateur ou créer un cookie de session. Les possibilités sont infinies pour l'implémentation finale de l'auth.

Si vous souhaitez appeler les API de Google, je vous recommande vivement de consulter le Google OAuth 2.0 Playground. Vous pourrez ainsi voir facilement quelles API vous pouvez appeler.

Utiliser l'accès offline avec votre propre backend

Pour utiliser l'accès offline, vous aurez besoin des éléments suivants :

• Un serveur HTTP

Dans cet exemple, j'utiliserai les technologies suivantes pour permettre l'accès hors ligne dans mon application :

• Hono

• Validateur Hono Zod

• Zod

• Hono JWT

• LowDb (une base de données simple)

Le code de cet exemple est disponible ici

Quant au code côté client, il ressemble à ceci :

import { Capacitor } from '@capacitor/core';
import { GoogleLoginOfflineResponse, SocialLogin } from '@capgo/capacitor-social-login';
import { usePopoutStore } from '@/popoutStore'; // <-- specific to my app

const baseURL = "[redacted]";

async function fullLogin() {
  await SocialLogin.initialize({
    google: {
      webClientId: '[redacted]',
      iOSClientId: '[redacted]',
      iOSServerClientId: 'The same value as webClientId',
      mode: 'offline' // <-- important
    }
  })
  const response = await SocialLogin.login({
    provider: 'google',
    options: {
      forceRefreshToken: true // <-- important
    }
  })

  if (response.provider === 'google') {
    const result = response.result as GoogleLoginOfflineResponse
    const res = await fetch(`${baseURL}/auth/google_offline`, {
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        serverAuthCode: result.serverAuthCode,
        platform: Capacitor.getPlatform()
      }),
      method: "POST"
    })

    if (res.status !== 200) {
      popoutStore.popout("Full google login failed", "check console");
      return
    }

    const { jwt } = await res.json();
    const userinfo = await fetch(`${baseURL}/auth/get_google_user`, {
      headers: {
        Authorization: `Bearer ${jwt}`
      }
    })
    if (userinfo.status !== 200) {
      popoutStore.popout("Full google (userinfo) login failed", "check console");
      return
    }
    popoutStore.popout("userinfo res", await userinfo.text());
  }
}

Notez ce qui manque ici : il n'y a aucun SocialLogin.refresh() appel dans l'application. C'est volontaire. En mode hors ligne Google, le refresh a lieu après que votre backend échange serverAuthCode et stocke le refresh token en toute sécurité.

Continuer depuis la configuration de Google Login

Si vous utilisez Configuration de Google Login pour planifier les flux d'authentification et de compte, le connecter à Utiliser @capgo/capacitor-social-login pour la capacité native dans Utiliser @capgo/capacitor-social-login @capgo/capacitor-social-login pour les détails d'implémentation dans @capgo/capacitor-social-login @capgo/capacitor-passkey pour les détails d'implémentation dans @capgo/capacitor-passkey @capgo/capacitor-native-biometric pour les détails d'implémentation dans @capgo/capacitor-native-biometric, et Authentification à deux facteurs pour les détails d'implémentation de l'authentification à deux facteurs.