SAML vs login federado com OAuth
Respostas:
Eles resolvem problemas diferentes.
SAML é um conjunto de padrões que foram definidos para compartilhar informações sobre quem é um usuário, quais são seu conjunto de atributos e fornecer a você uma maneira de conceder / negar acesso a algo ou até mesmo solicitar autenticação.
OAuth é mais sobre delegar acesso a algo. Basicamente, você está permitindo que alguém "aja" como você. É mais comumente usado para conceder APIs de acesso que podem fazer algo em seu nome.
São duas coisas completamente diferentes.
Alguns exemplos que podem ajudar.
OAuth pense em um twitter. Digamos que você esteja usando o Google Buzz e o Twitter e queira escrever um aplicativo para poder manter os dois sincronizados. Você basicamente pode estabelecer confiança entre seu aplicativo e o Twitter. A primeira vez que você vincula o aplicativo ao Twitter, executa o prompt clássico para fazer login no Twitter e, em seguida, aquela caixa de confirmação aparece e pergunta "Você gostaria de conceder acesso ao« nome do seu aplicativo »?" depois de clicar em "sim", a confiança foi estabelecida e agora seu aplicativo pode atuar como você no Twitter. Ele pode ler suas postagens, bem como fazer novas.
SAML - Para SAML pense em algum tipo de "acordo" entre dois sistemas de associação não relacionados. No nosso caso, podemos usar US Airways e Hertz. Não há um conjunto compartilhado de credenciais que possa levá-lo de um site para outro, mas digamos que a Hertz deseja oferecer um "acordo" com a US Airways. (Concedido eu sei que este é um exemplo extremo, mas tenha paciência comigo). Depois de comprar um vôo, eles vão oferecer um carro alugado gratuitamente para seus membros do presidente. A US Airways e a Hertz estabeleceriam alguma forma de confiança e alguma forma de identificar o usuário. Em nosso caso, nosso "ID federado" seria o endereço de e-mail, e seria um conjunto de confiança que a Hertz confia que o provedor de identidade da US Airways entregará um token preciso e seguro. Depois de reservar o voo, o provedor de identidade da US Airways geraria um token e preencheria como eles autenticaram o usuário, bem como "atributos" sobre a pessoa em nosso caso, o atributo mais importante seria seu nível de status na US Airways. Depois que o token é preenchido, ele passa por algum tipo de referência ou é codificado em uma url e, quando chegamos ao Hertz, ele olha o token, valida-o e agora pode permitir o aluguel de carro gratuitamente.
O problema com este exemplo SAML é que ele é apenas um caso de uso especializado entre muitos. SAML é um padrão e há muitas maneiras de implementá-lo.
Como alternativa, se você não se preocupa com a autorização, quase poderia argumentar que afirmar a autenticação via SAML e OpenID .
Dê uma olhada nesta explicação simples resumida aqui:
Muitas pessoas ficam confusas sobre as diferenças entre SAML, OpenID e OAuth, mas na verdade é muito simples. Embora haja alguma sobreposição, aqui está uma maneira muito simples de distinguir entre os três.
OpenID - logon único para consumidores
SAML - logon único para usuários corporativos
OAuth - autorização de API entre aplicativos
Para quem está confortável com os padrões de projeto OO, acho que há um bom corolário para os padrões de empacotamento . Pense nos padrões Facade , Decorator e Proxy . Fundamentalmente, são todos iguais, são apenas invólucros ... A diferença é que intenção de cada padrão .
Da mesma forma, SAML, OAuth e OpenID facilitam diferentes intenções por meio de um mecanismo subjacente comum , que é o redirecionamento para um provedor de serviços / autoridade de identidade para alguma interação privada, seguido pelo redirecionamento para o aplicativo de origem de terceiros.
Olhando ao redor na rede, você encontrará sobreposição entre as capacidades dos protocolos. A autenticação via OAuth é perfeitamente razoável. SSO sobre OAuth pode não fazer muito sentido, já que SAML e OpenID são voltados especificamente para identidade federada.
Para a própria pergunta, em um contexto corporativo, SAML parece mais apropriado do que OAuth para SSO . Aposto que se você olhar os aplicativos de terceiros que gostaria de integrar com suas identidades corporativas, verá que eles já foram projetados para se integrar com SAML / LDAP / Radius etc. IMO OAuth é mais apropriado para interação com a Internet entre aplicativos ou talvez aplicativos que compreendem uma Arquitetura Orientada a Serviços em um grande ambiente corporativo.
As regras de autorização também podem ser especificadas em um ambiente corporativo de outras maneiras. O LDAP é uma ferramenta comum para isso. Organizar usuários em grupos e associar privilégios de aplicativo à associação de grupo é uma abordagem generalizada. Acontece que o LDAP também pode ser usado para autenticação. O Active Directory é um ótimo exemplo, embora eu prefira OpenLDAP.
Bom artigo encontrado aqui
SAML (Security Assertion Markup Language) é um conjunto de padrões para alcançar Single Sign On (SSO), Federação e Gerenciamento de Identidade.
Exemplo : um usuário (principal) se autentica com um site de reserva de voo, AirFlyer (provedor de identidade), que tem SSO configurado via SAML com um site de reserva de transporte, Shuttler (provedor de serviço). Depois de autenticado no Flyer, o usuário pode reservar ônibus no Shuttler sem exigir autenticação
OAuth (Open Authorization) é um padrão para autorização de recursos. Não lida com autenticação.
Exemplo : Um aplicativo móvel de compartilhamento de fotos (consumidor OAuth) que permite aos usuários importar fotos de sua conta do Instagram (provedor OAuth) que envia um token de acesso temporário ou chave para o aplicativo de compartilhamento de fotos que expira após algumas horas.
SAML tem uma variedade de "perfis" para escolher, permitindo que outros usuários "façam login" em seu site. SAML-P ou SAML Passive é muito comum e bastante simples de configurar. O WS-Trust é semelhante e também permite a federação entre sites.
OAuth foi projetado para autorização. Você pode ler mais aqui:
SAMLé para autenticação - usado principalmente no cenário de logon único . OAuthé para autorização de representações de recursos.
JSON Web Token (JWT) é uma alternativa para SAML XML Tokens. JWT pode ser usado com OAuth
Uma boa referência é SAML vs. OAuth: qual devo usar?
Os termos federação realmente significam identidades de conexão entre sistemas. Ele está relacionado ao SSO, mas eles não são exatamente iguais. Achei esta postagem do blog realmente útil em termos do que a federação realmente significa.