OpenID Connect

As APIs de OAuth 2.0 do Google podem ser usadas para autenticação e autorização. Este documento descreve nossa implementação do OAuth 2.0 para autenticação, que está em conformidade com a especificação OpenID Connect e tem a certificação do OpenID (links em inglês). A documentação em Como usar o OAuth 2.0 para acessar as APIs do Google também se aplica a esse serviço. Se você quiser explorar esse protocolo de maneira interativa, recomendamos o Google OAuth 2.0 Playground. Para ajuda no Stack Overflow, marque suas perguntas com "google-oauth".

Como configurar o OAuth 2.0

Para que seu aplicativo possa usar o sistema de autenticação OAuth 2.0 do Google para login de usuário, é necessário configurar um projeto no Google API Console para receber credenciais OAuth 2.0, definir um URI de redirecionamento e, opcionalmente, personalizar as informações de marca que os usuários veem na tela de consentimento do usuário. Também é possível usar API Console para criar uma conta de serviço, ativar o faturamento, configurar a filtragem e realizar outras tarefas. Para mais detalhes, consulte a Ajuda doGoogle API Console.

Receber credenciais do OAuth 2.0

Você precisa de credenciais do OAuth 2.0, incluindo ID e chave secreta do cliente, para autenticar usuários e ter acesso às APIs do Google.

Para visualizar o ID do cliente e o segredo do cliente para uma determinada credencial do OAuth 2.0, clique no texto a seguir: Selecione credencial . Na janela que se abre, escolha seu projeto e a credencial desejada e clique em Exibir .

Ou visualize seu ID e segredo do cliente na página Credenciais em API Console :

1. Go to the Credentials page.
2. Clique no nome da sua credencial ou no ícone de lápis ( create ). Seu ID e segredo do cliente estão na parte superior da página.

Definir um URI de redirecionamento

O URI de redirecionamento definido em API Console determina para onde o Google envia respostas às suas solicitações de autenticação.

Para criar, exibir ou editar os URIs de redirecionamento para uma determinada credencial do OAuth 2.0, faça o seguinte:

1. Go to the Credentials page.
2. Na seção IDs do cliente OAuth 2.0 da página, clique em uma credencial.
3. Exibir ou editar os URIs de redirecionamento.

Se não houver uma seção IDs de cliente OAuth 2.0 na página Credenciais, seu projeto não terá credenciais OAuth. Para criar uma, clique em Criar credenciais .

Personalizar a tela de consentimento do usuário

Para os usuários, a experiência de autenticação do OAuth 2.0 inclui uma tela de consentimento com a descrição das informações que o usuário está lançando e dos termos aplicáveis. Por exemplo, quando o usuário faz login, ele pode ser solicitado a conceder ao app acesso ao endereço de e-mail e às informações básicas da conta. Para solicitar acesso a essas informações, use o parâmetro scope, que o app inclui na solicitação de autenticação. Também é possível usar escopos para solicitar acesso a outras APIs do Google.

A tela de consentimento do usuário também apresenta informações de branding, como o nome do produto, o logotipo e um URL da página inicial. Você controla as informações da marca na API Console.

Para ativar a tela de consentimento do seu projeto:

1. Abra o Consent Screen page no Google API Console .
2. If prompted, select a project, or create a new one.
3. Preencha o formulário e clique em Salvar .

A caixa de diálogo de consentimento a seguir mostra o que um usuário verá quando uma combinação de escopos do OAuth 2.0 e do Google Drive estiver presente na solicitação. Essa caixa de diálogo genérica foi gerada usando o Google OAuth 2.0 Playground. Portanto, ela não inclui informações de marca que seriam definidas na API Console.

Como acessar o serviço

O Google e terceiros fornecem bibliotecas que você pode usar para cuidar de muitos dos detalhes de implementação da autenticação de usuários e do acesso a APIs do Google. Os exemplos incluem o Google Identity Services e as bibliotecas de cliente do Google, que estão disponíveis para várias plataformas.

Se você optar por não usar uma biblioteca, siga as instruções no restante deste documento, que descreve os fluxos de solicitação HTTP que são a base das bibliotecas disponíveis.

Autenticar o usuário

A autenticação do usuário envolve a obtenção e a validação de um token de ID. Os tokens de ID são um recurso padronizado do OpenID Connect projetado para uso no compartilhamento de declarações de identidade na Internet.

As abordagens mais usadas para autenticar um usuário e conseguir um token de código são chamadas de "servidor" e "implícito". O fluxo de servidor permite que o servidor de back-end de um aplicativo verifique a identidade da pessoa usando um navegador ou dispositivo móvel. O fluxo implícito é usado quando um aplicativo do lado do cliente (normalmente, um aplicativo JavaScript em execução no navegador) precisa acessar as APIs diretamente, e não por meio do servidor back-end.

Este documento descreve como executar o fluxo do servidor para autenticar o usuário. O fluxo implícito é muito mais complicado devido aos riscos de segurança ao manipular e usar tokens no lado do cliente. Se for necessário implementar um fluxo implícito, recomendamos o uso do Google Identity Services.

Fluxo do servidor

Configure seu app no API Console para permitir que ele use esses protocolos e autentique os usuários. Quando um usuário tenta fazer login com o Google, você precisa:

1. Criar um token de estado anti-falsificação
2. Enviar uma solicitação de autenticação ao Google
3. Confirmar o token de estado anti-falsificação
4. Trocar code por token de acesso e de código
5. Receber informações do usuário com o token de ID
6. Autenticar o usuário

1. Criar um token de estado anti-falsificação

Você precisa proteger a segurança dos usuários, evitando ataques de falsificação de solicitações. A primeira etapa é criar um token de sessão exclusivo que mantém o estado entre o app e o cliente do usuário. Posteriormente, você corresponderá a esse token de sessão exclusivo com a resposta de autenticação retornada pelo serviço de login do Google OAuth para verificar se o usuário está fazendo a solicitação e não um invasor. Esses tokens são frequentemente chamados de tokens de falsificação de solicitação entre sites (CSRF, na sigla em inglês).

Uma boa escolha para um token de estado é uma string de aproximadamente 30 caracteres construída com o uso de um gerador de números aleatórios de alta qualidade. Outro é um hash gerado pela assinatura de algumas das variáveis de estado da sessão com uma chave que é mantida em segredo no back-end.

O código a seguir demonstra a geração de tokens exclusivos de sessão.

// 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. Enviar uma solicitação de autenticação ao Google

A próxima etapa é formar uma solicitação HTTPS GET com os parâmetros de URI apropriados. Observe o uso de HTTPS em vez de HTTP em todas as etapas desse processo. Conexões HTTP são recusadas. Recupere o URI base do documento de descoberta usando o valor de metadados authorization_endpoint. A discussão a seguir pressupõe que o URI base é https://accounts.google.com/o/oauth2/v2/auth.

Para uma solicitação básica, especifique os seguintes parâmetros:

• client_id, que você recebe do API Console Credentials page.
• response_type, que em uma solicitação de fluxo do código de autorização básica precisa ser code. Leia mais em response_type.
• scope, que em uma solicitação básica precisa ser openid email. Saiba mais em scope.
• redirect_uri precisa ser o endpoint HTTP no servidor que receberá a resposta do Google. O valor precisa corresponder exatamente a um dos URIs de redirecionamento autorizados para o cliente OAuth 2.0, que você configurou em API Console Credentials page. Se esse valor não corresponder a um URI autorizado, a solicitação falhará com um erro redirect_uri_mismatch.
• state precisa incluir o valor do token de sessão exclusivo de falsificação, bem como qualquer outra informação necessária para recuperar o contexto quando o usuário retornar ao aplicativo, por exemplo, o URL inicial. Saiba mais em state.
• nonce é um valor aleatório gerado pelo app que ativa a proteção de repetição quando presente.
• login_hint pode ser o endereço de e-mail do usuário ou a string sub, que é equivalente ao ID do Google do usuário. Se você não fornecer um login_hint e o usuário tiver feito login, a tela de consentimento incluirá uma solicitação de aprovação para liberar o endereço de e-mail do usuário no seu app. Leia mais em login_hint.
• Use o parâmetro hd para otimizar o fluxo do OpenID Connect para usuários de um domínio específico associado a uma organização do Google Cloud. Leia mais em hd.

Veja um exemplo de um URI completo de autenticação do OpenID Connect, com quebras de linha e espaços para legibilidade:

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

Os usuários precisam dar consentimento caso seu app solicite novas informações sobre eles ou se o app solicitar acesso à conta que não tenha sido aprovado anteriormente.

3. Confirmar token de estado anti-falsificação

A resposta é enviada ao redirect_uri que você especificou na solicitação. Todas as respostas são retornadas na string de consulta, conforme mostrado abaixo:

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

No servidor, você precisa confirmar que o state recebido do Google corresponde ao token de sessão criado na Etapa 1. Essa verificação de ida e volta ajuda a garantir que o usuário, e não um script malicioso, esteja fazendo a solicitação.

O código a seguir demonstra a confirmação dos tokens de sessão que você criou na Etapa 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. Troque code por token de acesso e de ID

A resposta inclui um parâmetro code, um código de autorização único que o servidor pode trocar por um token de acesso e um token de ID. O servidor faz essa troca enviando uma solicitação POST HTTPS. A solicitação POST é enviada para o endpoint de token, que precisa ser recuperado do documento de descoberta usando o valor de metadados token_endpoint. A discussão a seguir pressupõe que o endpoint é https://oauth2.googleapis.com/token. A solicitação precisa incluir os seguintes parâmetros no corpo POST:

A solicitação real pode ser semelhante ao exemplo a seguir:

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

Uma resposta bem-sucedida para essa solicitação contém os seguintes campos em uma matriz JSON:

5. Obter informações do usuário com o token de ID

Um token de código é um JWT (JSON Web Token), ou seja, um objeto JSON codificado em Base64 assinado criptograficamente. Normalmente, é essencial que você valide um token de código antes de usá-lo, mas, como está se comunicando diretamente com o Google por meio de um canal HTTPS sem intermediário e usando sua chave secreta do cliente para se autenticar no Google, você pode ter certeza de que o token recebido é realmente do Google e válido. Se o servidor transmitir o token de código para outros componentes do aplicativo, será extremamente importante que esses componentes validem o token antes de usá-lo.

Como a maioria das bibliotecas de API combina a validação com o trabalho de decodificar os valores codificados em base64url e analisar o JSON, você provavelmente acabará validando o token de qualquer maneira, à medida que acessar as declarações no token de ID.

Payload de um token de ID

Um token de ID é um objeto JSON que contém um conjunto de pares de nome/valor. Veja um exemplo formatado para legibilidade:

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

Os tokens de código do Google podem conter os seguintes campos (conhecidos como reivindicações):

6. Autenticar o usuário

Depois de receber informações do usuário com o token de ID, consulte o banco de dados do usuário do seu aplicativo. Se o usuário já existir no banco de dados, inicie uma sessão de aplicativo para esse usuário se todos os requisitos de login forem atendidos pela resposta da API do Google.

Se o usuário não existir no banco de dados, redirecione o usuário para o fluxo de inscrição de novo usuário. É possível registrar o usuário automaticamente com base nas informações recebidas do Google ou, no mínimo, preencher vários campos necessários no formulário de registro. Além das informações no token de ID, você pode ver informações adicionais do perfil de usuário nos nossos endpoints de perfil de usuário.

Assuntos avançados

As seções a seguir descrevem a API do Google OAuth 2.0 em mais detalhes. Estas informações são destinadas a desenvolvedores com requisitos avançados de autenticação e autorização.

Acesso a outras APIs do Google

Uma das vantagens de usar o OAuth 2.0 para autenticação é que seu aplicativo pode ter permissão para usar outras APIs do Google em nome do usuário (como YouTube, Google Drive, Agenda ou Contatos) ao mesmo tempo em que você autentica o usuário. Para fazer isso, inclua os outros escopos necessários na solicitação de autenticação enviada ao Google. Por exemplo, para adicionar a faixa etária do usuário à sua solicitação de autenticação, transmita um parâmetro de escopo de openid email https://www.googleapis.com/auth/profile.agerange.read. O usuário recebe uma solicitação adequada na tela de consentimento. O token de acesso que você recebe do Google permite acessar todas as APIs relacionadas aos escopos de acesso solicitados e concedidos.

Tokens de atualização

Na sua solicitação de acesso à API, é possível solicitar um token de atualização a ser retornado durante a troca code. Um token de atualização fornece ao seu aplicativo acesso contínuo às APIs do Google enquanto o usuário não está presente no seu aplicativo. Para solicitar um token de atualização, adicione o parâmetro access_type como offline em sua solicitação de autenticação.

Considerações:

• Armazene o token de atualização de maneira segura e permanente, porque você só pode conseguir um token de atualização na primeira vez que executar o fluxo de troca de código.
• Há limites para o número de tokens de atualização emitidos: um limite por combinação cliente/usuário e outro por usuário em todos os clientes. Se o aplicativo solicitar muitos tokens de atualização, ele poderá atingir esses limites. Nesse caso, os tokens de atualização mais antigos deixarão de funcionar.

Para mais informações, consulte Atualizar um token de acesso (acesso off-line).

Solicitação de novo consentimento

Você pode solicitar que o usuário autorize o app novamente definindo o parâmetro prompt como consent na solicitação de autenticação. Quando prompt=consent é incluído, a tela de consentimento é exibida sempre que seu app solicita autorização de escopos de acesso, mesmo que todos os escopos tenham sido concedidos anteriormente ao projeto das APIs do Google. Por esse motivo, inclua prompt=consent somente quando necessário.

Para saber mais sobre o parâmetro prompt, consulte prompt na tabela Parâmetros de URI de autenticação.

Parâmetros de URI de autenticação

A tabela a seguir fornece descrições mais completas dos parâmetros aceitos pela API de autenticação OAuth 2.0 do Google.

Como validar um token de ID

Você precisa validar todos os tokens de ID no servidor, a menos que saiba que eles foram enviados diretamente pelo Google. Por exemplo, seu servidor precisa verificar como autêntico todos os tokens de ID que ele recebe dos seus apps cliente.

Veja a seguir situações comuns em que é possível enviar tokens de ID ao servidor:

• Envio de tokens de ID com solicitações que precisam ser autenticadas. Os tokens de código informam o usuário específico que fez a solicitação e para qual cliente esse token de código foi concedido.

Os tokens de ID são confidenciais e podem ser usados indevidamente se forem interceptados. É preciso garantir que esses tokens sejam processados com segurança, transmitindo-os apenas por HTTPS e somente por dados POST ou dentro de cabeçalhos de solicitação. Se você armazenar tokens de ID no servidor, também precisará armazená-los com segurança.

Uma coisa que torna os tokens de ID úteis é o fato de que eles podem ser passados por diferentes componentes do app. Esses componentes podem usar um token de ID como um mecanismo de autenticação leve que autentica o aplicativo e o usuário. Mas antes de usar as informações no token de ID ou confiar nelas como uma declaração de que o usuário fez a autenticação, é necessário validá-las.

A validação de um token de ID requer várias etapas:

1. Verifique se o token de código foi assinado corretamente pelo emissor. Os tokens emitidos pelo Google são assinados usando um dos certificados encontrados no URI especificado no valor de metadados jwks_uri do documento de descoberta.
2. Verifique se o valor da declaração iss no token de ID é igual a https://accounts.google.com ou accounts.google.com.
3. Verifique se o valor da declaração aud no token de ID é igual ao ID do cliente do seu app.
4. Verifique se o prazo de validade (reivindicação exp) do token de código não passou.
5. Se você especificou um valor de hd parameter na solicitação, verifique se o token de ID tem uma declaração hd que corresponda a um domínio aceito associado a uma organização do Google Cloud.

As etapas de 2 a 5 envolvem apenas comparações de string e data que são bastante simples. Portanto, não as detalharemos aqui.

A primeira etapa é mais complexa e envolve a verificação da assinatura criptográfica. Para fins de depuração, você pode usar o endpoint tokeninfo do Google para comparar com o processamento local implementado no servidor ou dispositivo. Suponha que o valor do token de ID seja XYZ123. Em seguida, desfaça a referência do URI https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. Se a assinatura do token for válida, a resposta será o payload do JWT na forma de objeto JSON decodificado.

O endpoint tokeninfo é útil para depuração, mas, para fins de produção, recupere as chaves públicas do Google do endpoint de chaves e realize a validação localmente. Recupere o URI de chaves do documento de descoberta usando o valor de metadados jwks_uri. As solicitações para o endpoint de depuração podem ser limitadas ou sujeitas a erros intermitentes.

Como o Google altera as chaves públicas com pouca frequência, é possível armazená-las em cache usando as diretivas de cache da resposta HTTP e, na grande maioria dos casos, realizar a validação local com muito mais eficiência do que usando o endpoint tokeninfo. Essa validação requer a recuperação e a análise de certificados e a realização das chamadas criptográficas apropriadas para verificar a assinatura. Felizmente, há bibliotecas bem depuradas disponíveis em uma ampla variedade de linguagens para conseguir isso (consulte jwt.io).

Obtendo informações do perfil do usuário

Para ver mais informações de perfil do usuário, use o token de acesso (que o aplicativo recebe durante o fluxo de autenticação) e o padrão OpenID Connect:

1. Para estar em conformidade com OpenID, inclua os valores de escopo openid profile em sua solicitação de autenticação.

   Se você quiser que o endereço de e-mail do usuário seja incluído, especifique mais um valor de escopo de email. Para especificar profile e email, inclua o seguinte parâmetro no URI da solicitação de autenticação:

   scope=openid%20profile%20email

2. Adicione seu token de acesso ao cabeçalho de autorização e faça uma solicitação GET HTTPS para o endpoint de informações do usuário, que precisa ser recuperada do documento de descoberta usando o valor de metadados userinfo_endpoint. A resposta de informações do usuário inclui informações sobre o usuário, conforme descrito em OpenID Connect Standard Claims e o valor de metadados claims_supported do documento de descoberta. Os usuários ou as organizações deles podem optar por fornecer ou reter alguns campos. Portanto, é possível que você não receba informações de todos os campos para os escopos de acesso autorizados.

Documento de descoberta

O protocolo OpenID Connect requer o uso de vários endpoints para autenticar usuários e para solicitar recursos, incluindo tokens, informações do usuário e chaves públicas.

Para simplificar as implementações e aumentar a flexibilidade, o OpenID Connect permite o uso de um "documento de descoberta", um documento JSON encontrado em um local conhecido que contém pares de chave-valor que fornecem detalhes sobre a configuração do provedor do OpenID Connect, incluindo os URIs dos endpoints de autorização, token, revogação, userinfo e chaves públicas. O documento de descoberta para o serviço OpenID Connect do Google pode ser recuperado de:

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

Para usar os serviços OpenID Connect do Google, codifique o URI do documento de descoberta (https://accounts.google.com/.well-known/openid-configuration) no seu aplicativo. O aplicativo busca o documento, aplica as regras de armazenamento em cache na resposta e recupera os URIs de endpoints conforme necessário. Por exemplo, para autenticar um usuário, seu código recuperará o valor de metadados authorization_endpoint (https://accounts.google.com/o/oauth2/v2/auth no exemplo abaixo) como o URI base para solicitações de autenticação enviadas ao Google.

Veja um exemplo desse documento. Os nomes dos campos são aqueles especificados em OpenID Connect Discovery 1.0 (consulte o documento para saber o significado deles). Os valores são meramente ilustrativos e podem mudar, embora eles sejam copiados de uma versão recente do documento real do 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"
  ]
}

Você pode evitar uma viagem de ida e volta HTTP armazenando em cache os valores do documento de Descoberta. Os cabeçalhos de cache HTTP padrão são usados e devem ser respeitados.

Bibliotecas de cliente

As seguintes bibliotecas de cliente simplificam a implementação do OAuth 2.0 por meio da integração com frameworks conhecidos:

• Biblioteca cliente de APIs do Google para Java
• Biblioteca cliente de APIs do Google para Python
• Biblioteca cliente de APIs do Google para .NET
• Biblioteca cliente de APIs do Google para Ruby
• Biblioteca cliente de APIs do Google para PHP
• Biblioteca OAuth 2.0 para Google Web Toolkit
• Google Toolbox para Controladores Mac OAuth 2.0

Compliance com OpenID Connect

O sistema de autenticação OAuth 2.0 do Google é compatível com os recursos obrigatórios da especificação OpenID Connect Core. Qualquer cliente projetado para funcionar com o OpenID Connect deve interoperar com esse serviço, exceto no objeto de solicitação do OpenID.