SAML (SAML 1.0 e 2.0) e OpenID Connect (OIDC) são protocolos de identidade, projetados para autenticar usuários e fornecer dados de identidade para controle de acesso e como um método de comunicação para a identidade de um usuário. Qualquer um dos protocolos pode ser a base para os provedores de serviços de identificação (IdPs) que oferecem uma variedade de serviços e gestão de identidades do usuário e podem ser usados para aplicativos de login único (SSO).

Usado principalmente para aplicativos empresariais e governamentais, o SAML 2.0 é uma tecnologia madura que data de 2005 e suporta uma ampla variedade de funcionalidades de identidade. O SAML usa XML para seu formato de dados de identidade e HTTP ou SOAP simples para mecanismos de transporte de dados. O serviço que solicita e recebe dados do IdP é conhecido como a Parte Confiável (RP). Os dados de identidade do usuário, encapsulados em um documento XML chamado SAML Assertion, estão na forma de atributos, por exemplo, endereço de e-mail, nome, telefone, etc.

O SAML pode fornecer um mecanismo para identidade federada.

Antes que um provedor de serviço/parte confiável possa interagir com um IdP para autenticação do usuário, metadados devem ser trocados entre a RP e o IdP. Esses metadados, em formato XML, especificam endpoints, certificados de assinatura e criptografia, métodos de conexão suportados, formato de atributo, etc., que cada lado do binário SAML deve saber sobre o outro. Cada parte então usa os metadados da outra para configurar seu lado do sistema.

Para autenticar um usuário, a RP faz uma solicitação de autenticação (SAML AuthnRequest) para o IdP, usando um post de formulário HTTP (associação de POST) ou um redirecionamento com sequência de caracteres de consulta (associação de redirecionamento) para fazer a solicitação. Esta solicitação é normalmente assinada pela RP.

O IdP então verifica a solicitação, autentica o usuário e retorna uma Resposta SAML (contendo o SAML Assertion com os atributos acordados) para a RP em um formulário POST. Alguns IdPs suportam o consentimento do usuário para a liberação de atributos, mas isso não faz parte do protocolo SAML. Normalmente, as respostas e asserções SAML são assinadas digitalmente pelo IdP; as asserções também podem ser criptografadas se o aplicativo considerar a proteção HTTPS insuficiente.

O SAML suporta uma variedade de opções AuthnRequest que permitem o comportamento dinâmico; por exemplo, métodos de autenticação de usuário aceitáveis, desabilitação do SSO (forçando o login no IdP), restrição de IDPs de proxy, etc. Outras opções personalizadas também são suportadas.

Um protocolo relativamente novo, em constante evolução, o OIDC foi projetado para aplicativos web e móveis. Projetado para ser fácil de adotar e usar, o OIDC é uma extensão do OAuth2, com estruturas de dados em formato JSON (JWT) e fluxos HTTPS simples para transporte. Os dados de identidade do usuário ("claims") são emitidos em um token da web JSON (token de ID). As claims incluirão um identificador persistente e dados do usuário definidos pelos escopos solicitados. Convencionalmente, esse token é assinado digitalmente e também pode ser criptografado quando necessário.

Escopos do OIDC são usados para especificar quais possíveis claims ou grupos de claims podem ser retornados pelo IdP. Valores de escopo aceitáveis e as claims com que se relacionam dependem do IdP. Vários escopos e claims comuns são definidos no OIDC, como perfil, endereço, e-mail, etc.

Como exemplo, o escopo perfil geralmente conterá o nome do usuário e pode incluir sua foto, data de nascimento e outros dados pessoais, dependendo dos dados que o IdP tem e do que ele determina que deve ser incluído.

Como o SAML, antes que o OIDC possa ser usado, a RP e o IdP devem trocar alguns dados. No entanto, esses dados podem ser muito mais simples no OIDC. No mínimo, a RP obtém uma ID de cliente e um segredo do IdP, concorda com escopos potenciais e informa o IdP sobre um endpoint de URL para retornar códigos ou tokens.

Baseado no OAuth 2.0, o OIDC tem uma série de casos de uso, conhecidos como fluxos, que determinam exatamente como a RP e o IdP interagem. O fluxo mais simples é o fluxo implícito, onde a RP é redirecionada para o IdP com a ID do cliente e os valores de escopo desejados. Após o usuário ter sido autenticado e consentido em compartilhar esses dados, o IdP retorna as claims no token de ID redirecionando para o endpoint predefinido da RP. Fluxos mais seguros não envolvem o envio do token de ID diretamente e sim a devolução de um código de uso único, que a RP troca pelo token por meio de um POST de back-end. Além do token de ID, um token de acesso também pode ser emitido e ser usado pela RP para autorizar solicitações de recursos do usuário, cobertos pelo escopo.

O SAML tem um longo histórico de fornecer um meio seguro de troca de dados de identidade; portanto, é confiável para muitas organizações. Também é muito rico em recursos, cobrindo uma ampla variedade de requisitos de identidade.

O OIDC, sendo mais recente e dinâmico (especialmente no setor bancário europeu, com o Open Banking), ainda está atrás do SAML em termos de recursos. Por exemplo, a especificação dinâmica de IDPs de proxy ainda não é totalmente suportada. No entanto, para muitas aplicações em que apenas dados de identidade básicos são necessários, particularmente no espaço do consumidor, o OIDC é muito atraente, pois é muito mais fácil de usar do que o SAML e não requer o tratamento de XML peso-pesado do SAML.

Atualmente, o SAML é amplamente utilizado em identidades oficiais de cidadãos e autenticação empresarial. No entanto, isso está começando a mudar, com sistemas mais modernos exigindo o uso do OIDC no lugar do SAML. Isso se deve aos requisitos de processamento de dados mais leves vistos no OIDC, usando tokens JSON (token de ID) no lugar de XML. O OIDC é ideal para uso com aplicativos móveis e aplicativos da web de página única, onde o uso do SAML seria uma dificuldade.

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