OpenID Connect

Le API OAuth 2.0 di Google possono essere utilizzate sia per l'autenticazione sia per l'autorizzazione. Questo documento descrive la nostra implementazione di OAuth 2.0 per l'autenticazione, che è conforme alla specifica OpenID Connect ed è certificata OpenID. La documentazione disponibile anche in Utilizzo di OAuth 2.0 per accedere alle API di Google si applica a questo servizio. Se vuoi esplorare questo protocollo in modo interattivo, ti consigliamo di visitare Google OAuth 2.0 Playground. Per ricevere assistenza su Stack Overflow, tagga le tue domande con 'google-oauth'.

Configurazione di OAuth 2.0

Prima che l'applicazione possa utilizzare il sistema di autenticazione OAuth 2.0 di Google per l'accesso degli utenti, devi configurare un progetto nella Google API Console per ottenere le credenziali OAuth 2.0, impostare un URI di reindirizzamento e, facoltativamente, personalizzare le informazioni di branding che gli utenti vedono nella schermata per il consenso dell'utente. Puoi anche utilizzare API Console per creare un account di servizio, attivare la fatturazione, configurare i filtri e svolgere altre attività. Per maggiori dettagli, consulta la Guida Google API Console.

Ottenere le credenziali OAuth 2.0

Per autenticare gli utenti e ottenere l'accesso alle API di Google, devi disporre delle credenziali OAuth 2.0, inclusi un ID client e un client secret.

To view the client ID and client secret for a given OAuth 2.0 credential, click the following text: Select credential. In the window that opens, choose your project and the credential you want, then click View.

Or, view your client ID and client secret from the Credentials page in API Console:

1. Go to the Credentials page.
2. Click the name of your credential or the pencil (create) icon. Your client ID and secret are at the top of the page.

Imposta un URI di reindirizzamento

L'URI di reindirizzamento che hai impostato in API Console determina che Google invia le risposte alle tue richieste di autenticazione.

To create, view, or edit the redirect URIs for a given OAuth 2.0 credential, do the following:

1. Go to the Credentials page.
2. In the OAuth 2.0 client IDs section of the page, click a credential.
3. View or edit the redirect URIs.

If there is no OAuth 2.0 client IDs section on the Credentials page, then your project has no OAuth credentials. To create one, click Create credentials.

Personalizza la schermata per il consenso degli utenti

Per gli utenti, l'esperienza di autenticazione OAuth 2.0 include una schermata per il consenso che descrive le informazioni che l'utente sta rilasciando e i termini applicabili. Ad esempio, quando l'utente esegue l'accesso, è possibile che venga chiesto all'app di accedere al suo indirizzo email e alle informazioni di base sull'account. Devi richiedere l'accesso a queste informazioni utilizzando il parametro scope, che la tua app include nella sua richiesta di autenticazione. Puoi utilizzare gli ambiti anche per richiedere l'accesso ad altre API di Google.

La schermata per il consenso degli utenti mostra anche informazioni sul branding come il nome del prodotto, il tuo logo e l'URL di una home page. Puoi controllare le informazioni di branding nel API Console.

Per abilitare la schermata di consenso del tuo progetto:

1. Aprire Consent Screen page in Google API Console .
2. If prompted, select a project, or create a new one.
3. Compila il modulo e fai clic su Salva .

La seguente finestra di dialogo per il consenso mostra cosa vedrebbe un utente quando nella richiesta è presente una combinazione di ambiti OAuth 2.0 e Google Drive. Questa finestra di dialogo generica è stata generata utilizzando Google OAuth 2.0 Playground, quindi non include informazioni di branding che verrebbero impostate in API Console.

Accedi al servizio

Google e terze parti forniscono librerie che puoi utilizzare per gestire molti dei dettagli di implementazione dell'autenticazione degli utenti e dell'accesso alle API di Google. Alcuni esempi sono i servizi di identità Google e le librerie client di Google, disponibili per una serie di piattaforme.

Se scegli di non utilizzare una libreria, segui le istruzioni nella parte restante di questo documento, che descrivono i flussi di richiesta HTTP alla base delle librerie disponibili.

Autenticazione dell'utente

L'autenticazione dell'utente comporta l'ottenimento di un token ID e la convalida. I token ID sono una funzionalità standardizzata di OpenID Connect progettata per essere utilizzata nella condivisione di asserzioni di identità su Internet.

Gli approcci più utilizzati per l'autenticazione di un utente e per ottenere un token ID sono i flussi "server" e il flusso "implicit". Il flusso del server consente al server back-end di un'applicazione di verificare l'identità della persona utilizzando un browser o un dispositivo mobile. Il flusso implicito viene utilizzato quando un'applicazione lato client (in genere un'app JavaScript in esecuzione nel browser) deve accedere direttamente alle API anziché tramite il suo server di backend.

Questo documento descrive come eseguire il flusso del server per autenticare l'utente. Il flusso implicito è significativamente più complicato a causa dei rischi per la sicurezza nella gestione e nell'utilizzo dei token sul lato client. Se hai bisogno di implementare un flusso implicito, ti consigliamo vivamente di utilizzare i servizi di identità Google.

Flusso server

Assicurati di configurare la tua app nel API Console per consentirle di utilizzare questi protocolli e autenticare i tuoi utenti. Quando un utente prova ad accedere con Google, devi:

1. Creare un token di stato anti contraffazione
2. Inviare una richiesta di autenticazione a Google
3. Conferma il token di stato anti contraffazione
4. Exchange code per il token di accesso e il token ID
5. Ottenere informazioni utente dal token ID
6. Autenticare l'utente

1. Crea un token di stato anti contraffazione

Devi proteggere la sicurezza dei tuoi utenti impedendo attacchi di falsificazione. Il primo passaggio consiste nel creare un token di sessione univoco che tenga uno stato tra la tua app e il client dell'utente. Successivamente, associ questo token di sessione univoco alla risposta di autenticazione restituita dal servizio di accesso OAuth di Google per verificare che l'utente stia effettuando la richiesta e non un utente malintenzionato. Questi token sono spesso indicati come token di falsificazione cross-site (CSRF).

Una scelta valida per un token di stato è una stringa di circa 30 caratteri creata utilizzando un generatore di numeri casuali di alta qualità. Un altro è un hash generato dalla firma di alcune variabili di stato della sessione con una chiave che viene mantenuta segreta nel tuo backend.

Il codice seguente illustra la generazione di token di sessione univoci.

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

2. Invia una richiesta di autenticazione a Google

Il passaggio successivo consiste nel generare una richiesta HTTPS per GET con i parametri URI appropriati. Tieni presente l'utilizzo di HTTPS anziché HTTP in tutti i passaggi di questo processo; le connessioni HTTP vengono rifiutate. Devi recuperare l'URI di base dal documento Discovery utilizzando il valore dei metadati authorization_endpoint. La seguente discussione presuppone che l'URI di base sia https://accounts.google.com/o/oauth2/v2/auth.

Per una richiesta di base, specifica i seguenti parametri:

• client_id, che ottieni dall' API Console Credentials page.
• response_type, che in una richiesta di flusso di codice di autorizzazione di base deve essere code. Scopri di più all'indirizzo response_type.
• scope, che in una richiesta di base dovrebbe essere openid email. Scopri di più all'indirizzo scope.
• redirect_uri deve essere l'endpoint HTTP sul server che riceverà la risposta da Google. Il valore deve corrispondere esattamente a uno degli URI di reindirizzamento autorizzati per il client OAuth 2.0, configurato nel API Console Credentials page. Se questo valore non corrisponde a un URI autorizzato, la richiesta avrà esito negativo con un errore redirect_uri_mismatch.
• state dovrebbe includere il valore del token di sessione univoco anti-falso. Oltre a qualsiasi altra informazione necessaria per recuperare il contesto quando l'utente torna alla tua applicazione, ad esempio l'URL iniziale. Scopri di più all'indirizzo state.
• nonce è un valore casuale generato dalla tua app che consente la protezione della riproduzione quando presente.
• login_hint può essere l'indirizzo email dell'utente o la stringa sub, che equivale all'ID Google dell'utente. Se non fornisci un login_hint e l'utente è attualmente connesso, la schermata di consenso include una richiesta di approvazione per rilasciare l'indirizzo email dell'utente nella tua app. Scopri di più all'indirizzo login_hint.
• Utilizza il parametro hd per ottimizzare il flusso OpenID Connect per gli utenti di un particolare dominio associato a un'organizzazione Google Cloud. Scopri di più all'indirizzo hd.

Di seguito è riportato un esempio di URI di autenticazione OpenID Connect completo, con interruzioni di riga e spazi per una migliore leggibilità:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

Gli utenti devono dare il consenso se la tua app richiede nuove informazioni in merito o se richiede l'accesso all'account che non ha approvato in precedenza.

3. Conferma token di stato anti-falso

La risposta viene inviata all'elemento redirect_uri specificato nella richiesta. Tutte le risposte vengono restituite nella stringa di query, come mostrato di seguito:

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

Sul server devi confermare che il state ricevuto da Google corrisponda al token di sessione che hai creato nel passaggio 1. Questa verifica di andata e ritorno contribuisce a garantire che l'utente, non uno script dannoso, stia effettuando la richiesta.

Il codice seguente dimostra che i token di sessione sono stati creati al passaggio 1:

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if ($request->get('state') != ($app['session']->get('state'))) {
  return new Response('Invalid state parameter', 401);
}

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if (!request.queryParams("state").equals(
    request.session().attribute("state"))) {
  response.status(401);
  return GSON.toJson("Invalid state parameter.");
}

# Ensure that the request is not a forgery and that the user sending
# this connect request is the expected user.
if request.args.get('state', '') != session['state']:
  response = make_response(json.dumps('Invalid state parameter.'), 401)
  response.headers['Content-Type'] = 'application/json'
  return response

4. Scambia code con token di accesso e token ID

La risposta include un parametro code, un codice di autorizzazione una tantum che il server può scambiare con un token di accesso e un token ID. Il server effettua questa scambio inviando una richiesta HTTPS POST. La richiesta POST viene inviata all'endpoint del token, che dovresti recuperare dal documento di rilevamento utilizzando il valore dei metadati token_endpoint. La seguente discussione presuppone che l'endpoint sia https://oauth2.googleapis.com/token. La richiesta deve includere i seguenti parametri nel corpo POST:

La richiesta effettiva potrebbe essere simile all'esempio seguente:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your-client-id&
client_secret=your-client-secret&
redirect_uri=https%3A//oauth2.example.com/code&
grant_type=authorization_code

Una risposta corretta a questa richiesta contiene i seguenti campi in un array JSON:

5. Ottenere informazioni sull'utente dal token ID

Un token ID è un token web JWT, ovvero un oggetto JSON con codifica Base64 firmato crittograficamente. In genere, è fondamentale convalidare un token ID prima di utilizzarlo, ma poiché si comunica direttamente con Google tramite un canale HTTPS privo di intermediario e utilizzando il secret del client per autenticarsi a Google, si può essere certi che il token che si riceve provenga davvero da Google. Se il server trasmette il token ID ad altri componenti dell'app, è estremamente importante che gli altri componenti convalidino il token prima di utilizzarlo.

Poiché la maggior parte delle librerie API combina la convalida con il lavoro di decodifica dei valori con codifica base64url e l'analisi del JSON, probabilmente finirai per convalidare il token comunque quando accedi alle rivendicazioni nel token ID.

Payload di un token ID

Un token ID è un oggetto JSON contenente un insieme di coppie nome/valore. Ecco un esempio, formattato per la leggibilità:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

I token ID Google possono contenere i seguenti campi (detti rivendicazioni):

6. Autenticare l'utente

Dopo aver ottenuto le informazioni utente dal token ID, devi eseguire query sul database utente dell'app. Se l'utente esiste già nel tuo database, dovresti avviare una sessione dell'applicazione per quell'utente se tutti i requisiti di accesso sono soddisfatti dalla risposta dell'API di Google.

Se l'utente non esiste nel tuo database utente, devi reindirizzarlo al flusso di registrazione dei nuovi utenti. Potresti essere in grado di registrare automaticamente l'utente in base alle informazioni ricevute da Google o almeno puoi precompilare molti campi richiesti nel modulo di registrazione. Oltre alle informazioni contenute nel token ID, puoi ottenere ulteriori informazioni sul profilo utente presso i nostri endpoint del profilo utente.

Argomenti avanzati

Le sezioni seguenti descrivono l'API Google OAuth 2.0 in modo più dettagliato. Queste informazioni sono rivolte agli sviluppatori con requisiti avanzati relativi ad autenticazione e autorizzazione.

Accesso ad altre API di Google

Uno dei vantaggi di utilizzare OAuth 2.0 per l'autenticazione è che l'applicazione può ottenere l'autorizzazione all'uso di altre API Google per conto dell'utente (ad esempio YouTube, Google Drive, Calendar o Contatti) contemporaneamente all'autenticazione dell'utente. Per farlo, includi gli altri ambiti che ti occorrono nella richiesta di autenticazione che invii a Google. Ad esempio, per aggiungere la fascia d'età dell'utente alla tua richiesta di autenticazione, passa un parametro dell'ambito openid email https://www.googleapis.com/auth/profile.agerange.read. che venga visualizzato correttamente nella schermata di consenso. Il token di accesso che ricevi da Google ti consente di accedere a tutte le API relative agli ambiti di accesso che hai richiesto e che ti sono stati concessi.

Token di aggiornamento

Nella richiesta di accesso all'API, puoi richiedere la restituzione di un token di aggiornamento durante lo scambio di code. Un token di aggiornamento fornisce alla tua app accesso continuo alle API di Google mentre l'utente non è presente nella tua applicazione. Per richiedere un token di aggiornamento, aggiungi il parametro access_type a offline nella richiesta di autenticazione.

Considerazioni:

• Assicurati di archiviare il token di aggiornamento in modo sicuro e permanente, perché puoi ottenere un token di aggiornamento solo la prima volta che esegui il flusso di scambio del codice.
• Esistono limiti al numero di token di aggiornamento emessi: un limite per combinazione client/utente e un altro per utente per tutti i client. Se la tua applicazione richiede troppi token di aggiornamento, potrebbero verificarsi limiti. In questo caso, i token di aggiornamento meno recenti smetteranno di funzionare.

Per maggiori informazioni, consulta la pagina Aggiornamento di un token di accesso (accesso offline).

Richiesta di nuovo consenso

Puoi chiedere all'utente di autorizzare nuovamente l'app impostando il parametro prompt su consent nella tua richiesta di autenticazione. Se prompt=consent è inclusa, la schermata per il consenso viene visualizzata ogni volta che la tua app richiede l'autorizzazione degli ambiti di accesso, anche se tutti gli ambiti sono stati precedentemente concessi al tuo progetto API di Google. Per questo motivo, includi prompt=consent solo quando necessario.

Per scoprire di più sul parametro prompt, consulta prompt nella tabella Parametri URI di autenticazione.

Parametri URI di autenticazione

La tabella seguente fornisce descrizioni più complete dei parametri accettati dall'API OAuth 2.0 di Google.

Convalida di un token ID

Devi convalidare tutti i token ID sul tuo server, a meno che non abbia la certezza che provengono direttamente da Google. Ad esempio, il tuo server deve verificare come autentico i token ID che riceve dalle app client.

Di seguito sono riportate alcune situazioni comuni in cui potresti inviare token ID al tuo server:

• Invio di token ID con richieste che devono essere autenticate. I token ID indicano all'utente specifico che ha effettuato la richiesta e per quale client è stato concesso il token ID.

I token ID sono sensibili e possono essere usati in modo improprio se intercettati. Devi assicurarti che questi token vengano gestiti in modo sicuro trasmettendoli solo tramite HTTPS e solo tramite dati POST o all'interno delle intestazioni delle richieste. Se archivi token ID sul tuo server, devi archiviarli anche in modo sicuro.

Un aspetto che rende utili i token ID è il fatto che possono essere trasmessi su diversi componenti della tua app. Questi componenti possono utilizzare un token ID come meccanismo di autenticazione leggero che autentica l'app e l'utente. Prima di poter utilizzare le informazioni nel token ID o fare affidamento su di esse come un'affermazione che l'utente ha autenticato, devi convalidarle.

La convalida di un token ID richiede diversi passaggi:

1. Verifica che il token ID sia firmato correttamente dall'emittente. I token emessi da Google vengono firmati utilizzando uno dei certificati che si trovano all'URI specificato nel valore dei metadati jwks_uri del documento di rilevamento.
2. Verifica che il valore della rivendicazione iss nel token ID sia uguale a https://accounts.google.com o accounts.google.com.
3. Verifica che il valore della rivendicazione aud nel token ID sia uguale all'ID client della tua app.
4. Verifica che la data di scadenza (exp rivendicazione) del token ID non sia trascorsa.
5. Se hai specificato un valore parametro hd nella richiesta, verifica che il token ID abbia una rivendicazione hd corrispondente a un dominio accettato associato a un'organizzazione Google Cloud.

I passaggi da 2 a 5 prevedono solo confronti di stringhe e date che sono abbastanza chiari, quindi non li dettagliamo qui.

Il primo passaggio è più complesso e comporta il controllo della firma crittografica. Ai fini del debug, puoi utilizzare l'endpoint tokeninfo di Google per confrontarlo con l'elaborazione locale implementata sul tuo server o dispositivo. Supponiamo che il valore del token ID sia XYZ123. Quindi dovrai dereferenziare l'URI https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. Se la firma del token è valida, la risposta è il payload JWT nel suo modulo oggetto JSON decodificato.

L'endpoint tokeninfo è utile per il debug, ma per scopi di produzione, recupera le chiavi pubbliche di Google dall'endpoint delle chiavi ed esegui la convalida localmente. Devi recuperare l'URI delle chiavi dal documento Discovery utilizzando il valore dei metadati jwks_uri. Le richieste all'endpoint di debug potrebbero essere limitate o comunque soggette a errori intermittenti.

Poiché Google modifica le chiavi pubbliche solo raramente, puoi memorizzarle nella cache utilizzando le istruzioni cache della risposta HTTP e, nella maggior parte dei casi, eseguire la convalida locale in modo molto più efficiente rispetto all'utilizzo dell'endpoint tokeninfo. Questa convalida richiede il recupero e l'analisi dei certificati e l'esecuzione delle chiamate crittografiche appropriate per controllare la firma. Fortunatamente, esistono librerie ben sottoposte a debug disponibili in un'ampia varietà di linguaggi per eseguire questa operazione (vedi jwt.io).

Ottenere informazioni del profilo dell'utente

Per ottenere ulteriori informazioni sul profilo dell'utente, puoi utilizzare il token di accesso (che la tua applicazione riceve durante il flusso di autenticazione) e lo standard OpenID Connect:

1. Per essere conforme a OpenID, devi includere i valori dell'ambito openid profile nella richiesta di autenticazione.

   Se vuoi includere l'indirizzo email dell'utente, puoi specificare un valore aggiuntivo dell'ambito: email. Per specificare sia profile sia email, puoi includere il seguente parametro nell'URI della richiesta di autenticazione:

   scope=openid%20profile%20email

2. Aggiungi il token di accesso all'intestazione di autorizzazione ed effettua una richiesta GET HTTPS all'endpoint info sull'utente, che devi recuperare dal documento di rilevamento utilizzando il valore dei metadati userinfo_endpoint. La risposta delle informazioni utente include informazioni sull'utente, come descritto in OpenID Connect Standard Claims e il valore dei metadati claims_supported del documento di rilevamento. Gli utenti o le relative organizzazioni possono scegliere di fornire o trattenere alcuni campi, quindi potresti non ricevere informazioni per ogni campo relativo agli ambiti di accesso autorizzati.

Il documento di rilevamento

Il protocollo OpenID Connect richiede l'utilizzo di più endpoint per l'autenticazione degli utenti e per la richiesta di risorse tra cui token, informazioni degli utenti e chiavi pubbliche.

Per semplificare le implementazioni e aumentare la flessibilità, OpenID Connect consente di utilizzare un "documento di rilevamento", un documento JSON trovato in una posizione nota contenente coppie chiave-valore che forniscono dettagli sulla configurazione del provider OpenID Connect, compresi gli URI degli endpoint di autorizzazione, token, revoca, informazioni utente ed chiavi pubbliche. Il documento di rilevamento per il servizio OpenID Connect di Google può essere recuperato da:

https://accounts.google.com/.well-known/openid-configuration

Per utilizzare i servizi OpenID Connect di Google, devi eseguire l'hard-coding dell'URI del documento Discovery (https://accounts.google.com/.well-known/openid-configuration) nella tua applicazione. L'applicazione recupera il documento, applica le regole di memorizzazione nella cache nella risposta, quindi recupera gli URI endpoint da cui necessario. Ad esempio, per autenticare un utente, il codice recupera il valore dei metadati authorization_endpoint (https://accounts.google.com/o/oauth2/v2/auth nell'esempio di seguito) come URI di base per le richieste di autenticazione inviate a Google.

Ecco un esempio di questo documento; i nomi dei campi sono quelli specificati in OpenID Connect Discovery 1.0 (fai riferimento a tale documento per conoscere il relativo significato). I valori sono a scopo puramente illustrativo e potrebbero variare, anche se vengono copiati da una versione recente dell'effettivo documento Google Discovery:

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

Potresti evitare un round trip HTTP memorizzando nella cache i valori del documento Discovery. Vengono utilizzate le intestazioni standard di memorizzazione nella cache HTTP che devono essere rispettate.

Librerie client

Le seguenti librerie client semplificano l'implementazione di OAuth 2.0 mediante l'integrazione con i framework più usati:

• Libreria client delle API di Google per Java
• Libreria client delle API di Google per Python
• Libreria client delle API di Google per .NET
• Libreria client delle API di Google per Ruby
• Libreria client delle API di Google per PHP
• Libreria OAuth 2.0 per Google Web Toolkit
• Google Toolbox per i controller OAuth 2.0 per Mac

Conformità OpenID Connect

Il sistema di autenticazione OAuth 2.0 di Google supporta le funzionalità richieste della specifica OpenID Connect Core. Qualsiasi client progettato per funzionare con OpenID Connect deve interagire con questo servizio (ad eccezione dell'oggetto richiesta OpenID).