O que é OIDC: Desde por que precisamos até como funciona

Definição de OpenID Connect (OIDC)#

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

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. Através da análise de cenários específicos, veremos por que precisamos do OIDC em relação ao OAuth 2.0.

Conceitos-chave 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 aplicações de terceiros acesso aos 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 os recursos do usuário
• Cliente: A aplicação 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 do usuário.

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 devolve os recursos autorizados. No entanto, o servidor de recursos não sabe a identidade do usuário.

Isso não era um problema significativo no início do ecossistema da internet.

Entretanto, à medida que plataformas como Google, Facebook, Twitter e Github evoluíram, elas começaram a oferecer recursos de usuários ricos que se tornaram valiosos para aplicações de terceiros.

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

O OIDC foi criado para resolver esses desafios.

Papéis no OIDC#

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

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

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

Como funciona o OIDC?#

O processo de autenticação do OIDC é semelhante ao do OAuth 2.0, mas como o OP combina os papéis de Servidor de Autorização e 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 ao validar o Token de ID.

Um fluxo típico funciona assim:

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

Token de ID (token de identidade) no OIDC#

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

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

• iss (Emissor): Identificador único do Provedor OpenID que emite o Token de ID
• sub (Sujeito): Identificador único do usuário
• aud (Audiência): Identificador da aplicação cliente que recebe o Token de ID
• exp (Tempo 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, por favor, consulte: Token de ID.

Endpoint de informações do usuário#

O Endpoint de Informações do Usuário é uma API HTTP padronizada fornecida pelo OP para obter detalhes autenticados do usuário. Enviando requisições GET ou POST com um Token de Acesso para esse endpoint, é possível receber informações do usuário em 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 que o acesso a recursos protegidos no OAuth 2.0. Geralmente, as informações do usuário obtidas do endpoint de informações do usuário são mais abrangentes do que as contidas no 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 de Informações do Usuário, por favor, consulte: Endpoint de Informações do Usuário.

Observe que as informações do usuário que você recebe do endpoint de informações do usuário dependem dos escopos solicitados e 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, sendo o escopo openid 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 de email do usuário
• phone: Número de telefone do usuário
• address: Informações de endereço do usuário

Escopos diferentes retornam informações diferentes do usuário. Por exemplo, solicitar openid profile email retorna informações básicas do usuário e email no Token de ID e nas informações do usuário, enquanto openid profile email phone address inclui informações sobre 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, padronizando recursos de informações do usuário, e lançando as bases para recursos estendidos de gestão de identidade, o OIDC habilita vários cenários de gestão de identidade:

• Login único (SSO): O OIDC naturalmente suporta SSO através de informações de sessão de usuário estendidas, permitindo a gestão unificada do estado de login e o compartilhamento de identidade entre aplicações
• Gestão de estrutura organizacional: Informações de organização de usuários 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 em nível detalhado, incluindo informações de função 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 Logto, que fornece recursos de SSO, gestão de organização e gestão de permissões.