Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Collegamento dell'Account Google a OAuth

I collegamenti degli account vengono eseguiti utilizzando il flusso del codice di autorizzazione OAuth 2.0, standard di settore.

OAuth 2.1 e PKCE per gli agenti

Per gli agenti AI senza stato e le pipeline multimodali, è consigliabile applicare OAuth 2.1.

PKCE (Proof Key for Code Exchange): deve essere utilizzato per proteggere il flusso del codice di autorizzazione, impedendo attacchi di intercettazione.
Nessun flusso implicito: il flusso implicito espone i token di accesso nell'URL, il che rappresenta un rischio per la sicurezza degli ambienti degli agenti.

Il tuo servizio deve supportare gli endpoint di autorizzazione e scambio di token conformi a OAuth 2.0/2.1.

Create the project

To create your project to use account linking:

Go to the Google API Console.
Click Create project.
Enter a name or accept the generated suggestion.
Confirm or edit any remaining fields.
Click Create.

To view your project ID:

Go to the Google API Console.
Find your project in the table on the landing page. The project ID appears in the ID column.

Configure your OAuth Consent Screen

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

Open the OAuth consent screen page of the Google APIs console.
If prompted, select the project you just created.
On the "OAuth consent screen" page, fill out the form and click the “Save” button.

Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

Support email: For users to contact you with questions about their consent.

Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery
Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

Implementare il server OAuth

Un'implementazione del server OAuth 2.0 del flusso del codice di autorizzazione è costituita da due endpoint, che il tuo servizio rende disponibili tramite HTTPS. Il primo endpoint è l'endpoint di autorizzazione, che è responsabile di trovare o ottenere il consenso degli utenti per l'accesso ai dati. L'endpoint di autorizzazione presenta un'interfaccia utente di accesso agli utenti che non hanno ancora eseguito l'accesso e registra il consenso all'accesso richiesto. Il secondo endpoint è l'endpoint di scambio dei token, che viene utilizzato per ottenere stringhe criptate, chiamate token, che autorizzano un utente ad accedere al tuo servizio.

Quando un'applicazione Google deve chiamare una delle API del tuo servizio, Google utilizza questi endpoint insieme per ottenere l'autorizzazione dai tuoi utenti a chiamare queste API per loro conto.

Collegamento dell'account Google: flusso del codice di autorizzazione OAuth

Il seguente diagramma di sequenza descrive in dettaglio le interazioni tra l'utente, Google e gli endpoint del tuo servizio.

Figura 1. La sequenza di eventi nel flusso del codice di autorizzazione OAuth 2.0 per il collegamento dell'Account Google.

Ruoli e responsabilità

La seguente tabella definisce i ruoli e le responsabilità degli attori nel flusso OAuth di collegamento dell'Account Google (GAL). Tieni presente che in GAL Google funge da client OAuth, mentre il tuo servizio funge da provider di identità/servizi.

Attore / componente	Ruolo GAL	Responsabilità
App / server Google	Client OAuth	Avvia il flusso, riceve il codice di autorizzazione, lo scambia con token e li archivia in modo sicuro per accedere alle API del tuo servizio.
Il tuo endpoint di autorizzazione	Server di autorizzazione	Autentica gli utenti e ottiene il loro consenso a condividere l'accesso ai loro dati con Google.
Endpoint di scambio token	Server di autorizzazione	Convalida i codici di autorizzazione e i token di aggiornamento ed emette token di accesso al server Google.
URI di reindirizzamento Google	Endpoint di callback	Riceve il reindirizzamento dell'utente dal tuo servizio di autorizzazione con i valori `code` e `state`.

Una sessione del flusso del codice di autorizzazione OAuth 2.0 avviata da Google ha il seguente flusso:

Google apre l'endpoint di autorizzazione nel browser dell'utente. Se il flusso è iniziato su un dispositivo solo vocale per un'azione, Google trasferisce l'esecuzione a uno smartphone.
L'utente esegue l'accesso, se non l'ha già fatto, e concede a Google l'autorizzazione ad accedere ai propri dati con la tua API, se non l'ha già concessa.
Il tuo servizio crea un codice di autorizzazione e lo restituisce a Google. Per farlo, reindirizza il browser dell'utente a Google con il codice di autorizzazione allegato alla richiesta.
Google invia il codice di autorizzazione all'endpoint di scambio dei token, che verifica l'autenticità del codice e restituisce un token di accesso e un token di aggiornamento. Il token di accesso è un token di breve durata che il tuo servizio accetta come credenziali per accedere alle API. Il token di aggiornamento è un token a lunga durata che Google può archiviare e utilizzare per acquisire nuovi token di accesso quando scadono.
Una volta completato il flusso di collegamento dell'account, ogni richiesta successiva inviata da Google contiene un token di accesso.

Implementation Recipe

Segui questi passaggi per implementare il flusso del codice di autorizzazione.

Passaggio 1: gestisci le richieste di autorizzazione

Quando Google avvia il collegamento dell'account, reindirizza l'utente all'endpoint di autorizzazione. Per i contratti di protocollo dettagliati e i requisiti dei parametri, consulta l'endpoint di autorizzazione.

Per gestire la richiesta, esegui le seguenti azioni:

Convalida la richiesta:
- Verifica che client_id corrisponda all'ID client assegnato a Google.
- Verifica che redirect_uri corrisponda all'URL di reindirizzamento di Google previsto: none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- Verifica che response_type sia code.
Autentica l'utente:
- Controlla se l'utente ha eseguito l'accesso al tuo servizio.
- Se l'utente non ha eseguito l'accesso, invitalo a completare la procedura di accesso o registrazione.
Genera codice di autorizzazione:
- Crea un codice di autorizzazione univoco e non intuibile associato all'utente e al client.
- Imposta la scadenza del codice dopo circa 10 minuti.
Reindirizza di nuovo a Google:
- Reindirizza il browser all'URL fornito in redirect_uri.
- Aggiungi i seguenti parametri di query:
  - code: il codice di autorizzazione che hai generato.
  - state: il valore dello stato non modificato ricevuto da Google.

Passaggio 2: gestisci le richieste di scambio di token

L'endpoint di scambio di token elabora due tipi di richieste: lo scambio di codici con token e l'aggiornamento dei token di accesso scaduti. Per i contratti di protocollo dettagliati e i requisiti dei parametri, consulta Endpoint Token Exchange.

A. Scambiare codici di autorizzazione con token

Quando Google riceve il codice di autorizzazione, chiama l'endpoint di scambio dei token (POST) per recuperare i token.

Convalida la richiesta:
- Verifica client_id e client_secret.
- Verifica che il codice di autorizzazione sia valido e non scaduto.
- Verifica che redirect_uri corrisponda al valore utilizzato nel passaggio 1.
- Se la convalida non va a buon fine, restituisci un errore HTTP 400 Bad Request con {"error": "invalid_grant"}.
Token problema:
- Genera un refresh_token di lunga durata e un access_token di breve durata (in genere 1 ora).
- Restituisci un codice HTTP 200 OK con la risposta standard del token JSON.

B. Aggiornare i token di accesso

Quando il token di accesso scade, Google ne richiede uno nuovo utilizzando il token di aggiornamento.

Convalida la richiesta:
- Verifica client_id, client_secret e refresh_token.
- Se la convalida non va a buon fine, restituisci un errore HTTP 400 Bad Request con {"error": "invalid_grant"}.
Emetti un nuovo token di accesso:
- Genera un nuovo access_token temporaneo.
- Restituisci un codice HTTP 200 OK con la risposta del token JSON (inclusa facoltativamente una nuova risposta del token di aggiornamento).

Gestire le richieste di informazioni utente

L'endpoint userinfo è una risorsa protetta da OAuth 2.0 che restituisce attestazioni sull'utente collegato. L'implementazione e l'hosting dell'endpoint userinfo sono facoltative, ad eccezione dei seguenti casi d'uso:

Accesso a un account collegato con Google One Tap.
Abbonamento senza problemi su AndroidTV.

Dopo che il token di accesso è stato recuperato correttamente dall'endpoint del token, Google invia una richiesta all'endpoint userinfo per recuperare le informazioni di base del profilo dell'utente collegato.

intestazioni delle richieste endpoint userinfo
`Authorization header`	Il token di accesso di tipo Bearer.

Ad esempio, se l'endpoint userinfo è disponibile su https://myservice.example.com/userinfo, una richiesta potrebbe avere il seguente aspetto:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

Affinché l'endpoint userinfo possa gestire le richieste, segui questi passaggi:

Estrai il token di accesso dall'intestazione Autorizzazione e restituisci le informazioni per l'utente associato al token di accesso.
Se il token di accesso non è valido, restituisce un errore HTTP 401 Autorizzazione non autorizzata utilizzando l'intestazione della risposta WWW-Authenticate. Di seguito è riportato un esempio di risposta di errore userinfo:
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
Se durante la procedura di collegamento viene restituito un errore 401 Autorizzazione o qualsiasi altra risposta di errore non riuscita durante la procedura di collegamento, l'errore non sarà recuperabile, il token recuperato verrà eliminato e l'utente dovrà avviare nuovamente la procedura di collegamento.

Se il token di accesso è valido, restituisce e invia una risposta HTTP 200 con il seguente oggetto JSON nel corpo dell'HTTPS risposta:

{
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}

Se l'endpoint userinfo restituisce una risposta HTTP 200 riuscita, il token e le attestazioni recuperati vengono registrati in base all'Account Google dell'utente.

risposta endpoint userinfo
`sub`	Un ID univoco che identifica l'utente nel sistema.
`email`	Indirizzo email dell'utente.
`given_name`	Facoltativo:nome dell'utente.
`family_name`	Facoltativo:il cognome dell'utente.
`name`	Facoltativo:nome completo dell'utente.
`picture`	(Facoltativo) Immagine del profilo dell'utente.

Convalidare l'implementazione

Puoi convalidare l'implementazione utilizzando lo strumento OAuth 2.0 Playground.

Nello strumento, segui questi passaggi:

Fai clic su Configurazione per aprire la finestra di configurazione di OAuth 2.0.
Nel campo Flusso OAuth, seleziona Lato client.
Nel campo Endpoint OAuth, seleziona Personalizzato.
Specifica l'endpoint OAuth 2.0 e l'ID client che hai assegnato a Google nei campi corrispondenti.
Nella sezione Passaggio 1, non selezionare alcun ambito Google. Lascia invece questo campo vuoto o digita un ambito valido per il tuo server (o una stringa arbitraria se non utilizzi gli ambiti OAuth). Quando hai finito, fai clic su Autorizza API.
Nelle sezioni Passaggio 2 e Passaggio 3, segui il flusso OAuth 2.0 e verifica che ogni passaggio funzioni come previsto.

Puoi convalidare l'implementazione utilizzando lo strumento Demo di collegamento dell'Account Google.