O OpenID Connect ou OIDC é um protocolo de identidade que utiliza os mecanismos de autorização e autenticação do OAuth 2.0. A especificação final do OIDC foi publicada em 26 de fevereiro de 2014 e agora é amplamente adotada por muitos provedores de serviços de identificação na Internet.

O OIDC foi desenvolvido pela OpenID Foundation, que inclui empresas como Google e Microsoft. Enquanto o OAuth 2.0 é um protocolo de autorização, o OIDC é um protocolo de autenticação de identidade e pode ser usado para verificar a identidade de um usuário para um serviço cliente, também chamada Parte Confiável. Além disso, as claims dos usuários, como, por exemplo, nome, endereço de e-mail, etc., também podem ser compartilhadas mediante solicitação.

Uma ampla variedade de clientes pode usar o OpenID Connect (OIDC) para identificar usuários, de aplicativos de página única (SPA) a aplicativos nativos e móveis. Também pode ser usado para login único (SSO) em todos os aplicativos. O OIDC usa JSON Web Tokens (JWT) e fluxos HTTP e evita o compartilhamento de credenciais do usuário com serviços.

O OpenID Connect tem consentimento integrado. Isso é importante, pois o OIDC é usado com frequência em serviços voltados para o consumidor (por exemplo, uma Parte Confiável), onde o compartilhamento de dados pessoais requer o consentimento explícito do usuário.

Esses recursos, juntamente com a simplicidade de implementação, tornam o OpenID Connect um protocolo útil quando a identidade de um usuário é necessária, e uma alternativa poderosa ao SAML 2.0 mais complexo. Também é especialmente adequado para aplicativos móveis.

O OIDC utiliza o OAuth 2.0 como um protocolo subjacente. As principais extensões são um valor de escopo especial ("openid"), o uso de um token extra (o token de ID, que encapsula as claims de identidade no formato JSON) e a ênfase na autenticação em vez da autorização. Além disso, no OIDC, o termo "fluxo" é usado no lugar da "concessão" do OAuth2.

O provedor de OIDC (geralmente chamado de provedor de OpenID ou provedor de identidade ou IdP) realiza autenticação do usuário, consentimento do usuário e emissão de token. O cliente ou serviço que solicita a identidade de um usuário é normalmente chamado de Parte Confiável (RP). Pode ser, por exemplo, um aplicativo da web, mas também um aplicativo JavaScript ou um aplicativo móvel. \ nConstruído sobre o OAuth 2.0, o OpenID Connect usa tokens para fornecer uma camada de identidade simples integrada à estrutura de autorização subjacente. Esta integração implica o uso dos seguintes tipos de token:

Token de ID: Específico para OIDC, o uso principal deste token no formato JWT é fornecer informações sobre o resultado da operação de autenticação. Mediante solicitação, pode fornecer os dados de identidade que descrevem um perfil de usuário. Os dados sobre o resultado da autenticação e as informações do perfil do usuário são chamados de claims. As claims do perfil do usuário podem ser quaisquer dados que sejam pertinentes à Parte Confiável para fins de identificação, como uma ID persistente, endereço de e-mail, nome, etc.

Token de acesso: Definido no OAuth2, este token de vida curta (opcional) fornece acesso a recursos específicos do usuário, conforme definido nos valores do escopo na solicitação ao servidor de autorização.

Token de atualização: Vindo das especificações do OAuth2, esse token geralmente tem vida longa e pode ser usado para obter novos tokens de acesso.

Os tokens de ID devem ser assinados digitalmente para evitar adulterações. Eles também podem ser criptografados para fornecer privacidade adicional, embora, em muitos casos, a segurança da camada de transporte (HTTPS) seja suficiente. Para SPAs e aplicativos móveis, a criptografia de token de ID não é útil, pois a chave de descriptografia pode ser descoberta facilmente.

A escolha do fluxo do OpenID Connect depende do tipo de aplicativo e de seus requisitos de segurança. Existem três fluxos comuns:

• Fluxo implícito: Neste fluxo, comumente usado por SPAs, os tokens são devolvidos diretamente para a RP em um URI de redirecionamento.
• Fluxo de código de autorização: Este fluxo é mais seguro do que o fluxo implícito, pois os tokens não são retornados diretamente. Para aplicativos nativos/móveis e SPAs, a segurança pode ser aprimorada usando uma chave de prova para troca de código.
• Fluxo híbrido: Combinando os fluxos de código implícitos e de autorização, neste caso o token de ID é devolvido diretamente para a RP, mas o token de acesso não. Em vez disso, é retornado um código de autorização que é trocado por um token de acesso.

O Provedor do OpenID determina os métodos de autenticação disponíveis para autenticar os usuários ao acessar sua conta do IdP e, possivelmente, consentir em liberar seus dados de identidade para a RP. As especificações do OIDC não dizem nada sobre a mecânica da própria autenticação do usuário. O IdP pode oferecer fatores únicos ou múltiplos, por exemplo,

• Nome de usuário/senha
• Código de uso único entregue fora da banda, por exemplo, por SMS ou e-mail
• Código gerado pelo aplicativo (OATH, TOTP ou HOTP)
• Biométrico por meio do aplicativo
• Federado (por exemplo, Facebook, GoogleID)

A RP também pode ter algo a dizer sobre a autenticação do IdP. Por exemplo, a autenticação multifator pode ser solicitada. No entanto, a maneira como um IdP autentica os usuários está fora do escopo do OIDC.

Continue lendo a Introdução ao IAM para conhecer outros tópicos sobre a Gestão de Identidades e Acesso.