O que é OIDC: Por que precisamos dele e como ele funciona

Definição de OpenID Connect (OIDC)#

OpenID Connect (OIDC) é um protocolo de autenticação de identidade construído em cima do OAuth 2.0. Enquanto o OAuth 2.0 fornece apenas autorização, o OIDC acrescenta capacidades de autenticação, oferecendo uma solução mais padronizada para cenários de autorização e autenticação de usuário.

Simplificando: OIDC = Protocolo de Autorização + Autenticação de Identidade.

Por que o OIDC é necessário?#

Para entender por que o OIDC é necessário, vamos primeiro explorar os conceitos centrais e o fluxo de trabalho do OAuth 2.0, e suas limitações em aplicações práticas. Analisando cenários específicos, veremos por que precisamos do OIDC em vez do OAuth 2.0.

Conceitos principais e fluxo de autorização do OAuth 2.0#

OAuth 2.0 (Open Authorization) é um protocolo de autorização que permite que os usuários concedam a aplicativos de terceiros acesso a seus recursos sem compartilhar suas credenciais, como nomes de usuário e senhas. Ele envolve quatro papéis principais:

• Proprietário do Recurso: O usuário que possui os recursos
• Servidor de Recursos: O servidor que armazena recursos de usuários
• Cliente: O aplicativo de terceiros que solicita acesso aos recursos do usuário
• Servidor de Autorização: O servidor que verifica a identidade do usuário e emite tokens de acesso

Um fluxo típico de autorização do OAuth 2.0 funciona assim:

Como mostrado, o OAuth 2.0 lida principalmente com a emissão de tokens de acesso para que clientes de terceiros acessem recursos de usuários.

A limitação do OAuth 2.0#

O protocolo OAuth 2.0 foca apenas na emissão de tokens de acesso. O servidor de recursos valida esses tokens e retorna os recursos autorizados. No entanto, o servidor de recursos não conhece a identidade do usuário.

Isso não era um problema significativo no ecossistema inicial da internet.

No entanto, à medida que plataformas como Google, Facebook, Twitter e Github evoluíram, começaram a oferecer ricos recursos de usuários que se tornaram valiosos para aplicativos de terceiros.

Embora o OAuth 2.0 seja excelente para autorizar o acesso de terceiros a recursos de usuários, ele tem limitações. Um cenário típico é: já que a informação do usuário também é um recurso, quando aplicativos de terceiros precisam acessar informações básicas do usuário, diferentes plataformas (como Google, Facebook, Twitter) retornam informações do usuário em formatos diferentes, criando desafios para desenvolvedores.

O OIDC foi criado para enfrentar esses desafios.

Papéis no OIDC#

Para habilitar a autenticação de usuários em cima do OAuth 2.0 e lidar com suas limitações, o OIDC introduziu três papéis:

• Usuário Final (EU): O usuário final, correspondente ao Proprietário do Recurso do OAuth 2.0
• Parte Dependente (RP): A parte dependente, correspondente ao Cliente do OAuth 2.0
• Provedor de OpenID (OP): O provedor de serviço de autenticação de identidade, correspondente ao Servidor de Autorização e ao Servidor de Recursos do OAuth 2.0

O OP é o papel central, fornecendo tanto a funcionalidade de autorização do OAuth 2.0 quanto tratando informações do usuário como um recurso separado.

Como o OIDC funciona?#

O processo de autenticação do OIDC é semelhante ao do OAuth 2.0, mas como o OP combina os papéis do Servidor de Autorização e do Servidor de Recursos, ele retorna tanto um Token de Acesso quanto um Token de ID. O Token de ID contém informações de identidade do usuário, e o RP pode verificar a identidade do usuário validando o Token de ID.

Um fluxo de trabalho típico se parece com isso:

Isso padroniza como as informações do usuário são obtidas em diferentes plataformas, eliminando a necessidade de aplicativos de terceiros lidarem com diferenças específicas de plataformas.

Token de ID (token de identidade) no OIDC#

Quando os usuários autorizam aplicativos de terceiros, o OP retorna tanto um Token de Acesso do OAuth 2.0 quanto um Token de ID em formato JWT. Este Token de ID contém informações de identidade do usuário, como ID, nome de usuário, email e avatar. O RP pode confirmar a identidade do usuário validando o Token de ID.

Como um JWT, o Token de ID contém declarações padronizadas, incluindo essas declarações principais obrigatórias:

• iss (Emitente): Identificador único do Provedor de OpenID emitindo o Token de ID
• sub (Assunto): Identificador único do usuário
• aud (Audiência): Identificador do aplicativo cliente recebendo o Token de ID
• exp (Data de Expiração): Quando o Token de ID expira
• iat (Emitido Em): Quando o Token de ID foi emitido

Para informações detalhadas sobre tokens de ID, consulte: Token de ID.

Endpoint Userinfo#

O Endpoint Userinfo é uma API HTTP padronizada fornecida pelo OP para obter detalhes autenticados do usuário. Ao enviar solicitações GET ou POST com um Token de Acesso para este endpoint, você pode receber informações do usuário no formato JSON. Os dados retornados incluem campos padronizados como ID único do usuário (sub), nome de usuário (name), email e imagem.

O processo de obtenção de informações do usuário segue o mesmo padrão de acesso a recursos protegidos no OAuth 2.0. Geralmente, as informações do usuário obtidas do endpoint userinfo são mais abrangentes do que as do token de ID, já que o token de ID serve principalmente para autenticação de identidade e informações básicas do usuário.

Para informações detalhadas sobre o endpoint Userinfo, consulte: Endpoint Userinfo.

Note que as informações do usuário que você recebe do endpoint userinfo dependem dos escopos solicitados e das permissões concedidas durante a autorização.

Escopos no OIDC#

Escopos no OIDC definem quais informações do usuário o RP pode acessar. O OIDC define escopos padrão, com o escopo openid sendo obrigatório nos fluxos de autenticação do OIDC.

Escopos padrão comuns incluem:

• openid: Indica uma solicitação de autenticação OIDC
• profile: Informações básicas do usuário, como nome e avatar
• email: Informações do email do usuário
• phone: Número de telefone do usuário
• address: Informações de endereço do usuário

Diferentes escopos retornam diferentes informações do usuário. Por exemplo, solicitar openid profile email retorna informações básicas do usuário e email no Token de ID e no Userinfo, enquanto openid profile email phone address inclui informações de número de telefone e endereço também.

Gestão de identidade baseada no OIDC#

O OIDC não é apenas um protocolo de autenticação; é uma ferramenta poderosa para construir sistemas de gestão de identidade flexíveis e escaláveis. Ao adicionar uma camada de autenticação ao OAuth 2.0, padronizar recursos de informações do usuário e estabelecer a base para extensões de recursos de gestão de identidade, o OIDC possibilita vários cenários de gestão de identidade:

• Single Sign-On (SSO): O OIDC naturalmente suporta SSO através de informações de sessão do usuário estendidas, permitindo gestão unificada do estado de login e compartilhamento de identidade entre aplicativos
• Gestão de estrutura organizacional: Informações organizacionais de usuário estendidas podem gerenciar estruturas organizacionais complexas, incluindo hierarquias departamentais e relações de grupos de usuários
• Gestão de permissões: Atributos de permissão de usuário estendidos possibilitam controle de acesso a recursos de forma granular, incluindo informações de papel e configuração de políticas de permissão

A flexibilidade do OIDC se adapta às necessidades em evolução de gestão de identidade. Muitos sistemas de gestão de identidade são construídos com base no OIDC, como o Logto, que fornece recursos de SSO, gestão de organizações e gestão de permissões.