Qual é a diferença entre OpenID e SAML?

Qual é a diferença entre OpenID e SAML?

OpenID 2.0 original vs SAML

Eles são dois protocolos diferentes de autenticação e diferem no nível técnico.

À distância, as diferenças começam quando os usuários iniciam a autenticação. Com o OpenID, um login de usuário geralmente é um endereço HTTP do recurso responsável pela autenticação. Por outro lado, o SAML é baseado em uma confiança explícita entre o site e o provedor de identidade, portanto, é incomum aceitar credenciais de um site desconhecido.

As identidades OpenID são fáceis de percorrer na rede. Como desenvolvedor, você pode aceitar usuários provenientes de provedores OpenID muito diferentes. Por outro lado, um provedor SAML geralmente precisa ser codificado com antecedência e você associa seu aplicativo apenas aos provedores de identidade selecionados. É possível restringir a lista de provedores de identidade OpenID aceitos, mas acho que isso seria contrário ao conceito geral de OpenID.

Com o OpenID, você aceita identidades provenientes de servidores arbitrários. Alguém afirma ser http://someopenid.provider.com/john.smith. Como você vai combinar isso com um usuário no seu banco de dados? De alguma forma, por exemplo, armazenando essas informações com uma nova conta e reconhecendo quando o usuário visita seu site novamente. Observe que qualquer outra informação sobre o usuário (incluindo seu nome ou email) não pode ser confiável!

Por outro lado, se houver uma confiança explícita entre seu aplicativo e o provedor de ID SAML, você poderá obter informações completas sobre o usuário, incluindo o nome e o email, e essas informações podem ser confiáveis, apenas por causa da relação de confiança. Isso significa que você tende a acreditar que o Provedor de ID validou de alguma forma todas as informações e pode confiar nelas no nível do aplicativo. Se os usuários vierem com tokens SAML emitidos por um provedor desconhecido, seu aplicativo apenas recusará a autenticação.

OpenID Connect vs SAML

(seção adicionada em 07-2017, expandida em 08-2018)

Esta resposta data de 2011 e, na época, OpenID significava OpenID 2.0 . Posteriormente, em algum momento de 2012, o OAuth2.0 foi publicado e, em 2014, o OpenID Connect (uma linha do tempo mais detalhada aqui ).

Para quem lê isso hoje em dia - o OpenID Connect não é o mesmo OpenID ao qual a resposta original se refere , é um conjunto de extensões para o OAuth2.0.

Embora essa resposta possa esclarecer um pouco do ponto de vista conceitual, uma versão muito concisa para alguém que vem com o background do OAuth2.0 é que o OpenID Connect é de fato o OAuth2.0, mas adiciona uma maneira padrão de consultar as informações do usuário , após o token de acesso. está disponível.

Referindo-se à pergunta original - qual é a principal diferença entre o OpenID Connect (OAuth2.0) e o SAML, é como a relação de confiança é criada entre o aplicativo e o provedor de identidade:

• O SAML cria a relação de confiança em uma assinatura digital, os tokens SAML emitidos pelo provedor de identidade são XMLs assinados, o aplicativo valida a própria assinatura e o certificado que ela apresenta. As informações do usuário estão incluídas em um token SAML, entre outras informações.

• OAuth2 cria a relação de confiança em uma chamada HTTPs direta do aplicativo para a identidade. A solicitação contém o token de acesso (obtido pelo aplicativo durante o fluxo do protocolo) e a resposta contém as informações sobre o usuário.

• O OpenID Connect expande ainda mais isso para possibilitar a obtenção da identidade sem essa etapa extra que envolve a chamada do aplicativo para o provedor de identidade. A idéia é baseada no fato de que os provedores do OpenID Connect emitem dois tokens, o access_tokenmesmo que o OAuth2.0 emite e o novo, o id_tokenqual é um token JWT , assinado pelo provedor de identidade. O aplicativo pode usar o id_tokenpara estabelecer uma sessão local, com base nas declarações incluídas no token JWT, mas id_token não pode ser usado para consultar outros serviços, tais chamadas para serviços de terceiros ainda devem usar oaccess_token. Você pode pensar no OpenID Connect como um híbrido entre o SAML2 (token assinado) e OAuth2 (token de acesso), pois o OpenID Connect envolve apenas os dois.

OpenID e SAML2 são ambos baseados no mesmo conceito de identidade federada. A seguir estão algumas das diferenças entre eles ..

1. O SAML2 suporta saída única - mas o OpenID não
2. Os provedores de serviços SAML2 são acoplados aos Provedores de Identidade SAML2, mas as partes confiáveis ​​do OpenID não são acopladas aos Provedores OpenID. O OpenID possui um protocolo de descoberta que descobre dinamicamente o provedor OpenID correspondente, assim que um OpenID é fornecido. O SAML tem um protocolo de descoberta baseado no Protocolo do Serviço de Descoberta de Provedores de Identidade.
3. Com o SAML2, o usuário é acoplado ao SAML2 IdP - seu identificador SAML2 é válido apenas para o SAML2 IdP que o emitiu. Mas com o OpenID, você é o proprietário do seu identificador e pode mapeá-lo para qualquer provedor de OpenID que desejar.
4. O SAML2 possui ligações diferentes, enquanto a única ligação que o OpenID possui é HTTP
5. O SAML2 pode ser iniciado pelo Provedor de Serviços (SP) ou pelo IdP (Provedor de Identidade). Mas o OpenID sempre SP iniciado.
6. O SAML 2 é baseado em XML, enquanto o OpenID não.
7. A maioria dos aplicativos desenvolvidos nos últimos 3 anos suportava apenas o OpenID Connect.
8. 92% das solicitações de autenticação 8B + que o Microsoft Azure AD entregou em maio de 2018 eram de aplicativos habilitados para OpenID Connect.

Deixando de lado os detalhes técnicos, sendo muito tarde para a festa, o que eu entendo que a maior diferença entre o SAML e outros padrões de autenticação (incluindo o OpenID) é que

O SAML exige que o Identity Provider (IDP) e o Service Provider (SP) se conheçam antes, pré-configurados , estáticos autenticação e autorização. O OpenId (+ Connect) não possui esse requisito.

Isso é importante para os deslocados internos que desejam controle total sobre quem está acessando os dados. Parte do padrão é configurar o que é fornecido para SPs específicos.

Por exemplo, um banco pode não querer que seus usuários acessem quaisquer serviços, exceto alguns predefinidos (devido a regulamentos ou outras regras estritas de segurança).

Isso não significa que um OpenId IDP não possa impor essa restrição. Um implementador OpenID pode controlar o acesso, mas esse não é o objetivo do OpenID.

Diferente da diferença de controle de acesso predefinida, estrita, estática, conceitualmente (não tecnicamente), OpenID Connect e o SAML são semelhantes.

Resumindo, se você é um SP, deve apoiar o que seus clientes exigem:

1. Se o seu cliente for um usuário final individual (usando o ID do Google, por exemplo), esqueça o SAML. Use o OpenID Connect.
2. Se o seu cliente for um banco que deseja que seus funcionários usem seu serviço e exporte apenas uma lista estática de dados que fornecerá ao seu serviço, provavelmente o banco desejará que você suporte o SAML. O banco pode ter uma implementação OpenID com restrição de cliente, que será seu dia de sorte :)

O SAML e o OpenID podem atuar como provedor de identidade (IdP abreviado), isto é, protocolo de autenticação descentralizado (identidade de logon único).

O S egurança Um ssertion M arkup L anguage ( SAML ) é um conjunto de perfis para a troca de dados de autenticação e de autorização em vários domínios de segurança. No modelo de domínio SAML, um provedor de identidade é um tipo especial de autoridade de autenticação. Especificamente, um provedor de identidade SAML é uma entidade do sistema que emite asserções de autenticação em conjunto com um perfil SSO do SAML. Uma terceira parte confiável que consome essas asserções de autenticação é chamada de provedor de serviços SAML. Fonte

O ID da caneta C onnect ( OIDC ) é uma camada de autenticação sobre o OAuth 2.0, uma estrutura de autorização. O padrão é controlado pela OpenID Foundation. OAuth é para protocolo de autorização, em vez de protocolo de autenticação e OpenID especificamente projetado como protocolo de autenticação. O OIDC usa JSON Web Tokens (JWT) simples, eles são mais fáceis de consumir por JavaScript.

Cenário de caso de uso:

Use o OAuth se seus usuários quiserem apenas fazer login no Facebook ou Twitter. Use o OpenID se seus usuários forem barba de pescoço que executam seus próprios provedores de OpenID porque "não querem que mais ninguém possua sua identidade".

Fonte