Dentro dos conceitos mais atuais para o desenvolvimento seguro, tratar do aspecto da autenticação é um dos mais importantes. Para este artigo vamos conversar um pouco sobre estes dois modelos, o SAML e o OAuth.
Você também pode ouvir esse conteúdo:
Acredito que um primeiro passo seja falarmos um pouco sobre o que é Federated Identity, pois isso vai ser importante para entendermos porquê esses dois conceitos são tão usados quando trabalhamos com desenvolvimento seguro.
Primeiro vamos a um disclaimer, sabendo que o SAML é um padrão de autenticação enquanto o OAuth é um padrão de autorização, tentaremos explicar aqui o uso destes dois padrões.
O que é Federated Identity?
Se for preciso explicar o que é Federation Identity em poucas palavras, eu diria que é a possibilidade de um usuário ser autenticado em vários sistemas, após ser validado por um mecanismo de autenticação central. Esse processo está relacionado com o SSO ou single sign-on, que é um subconjunto de Federated Identity Management.
Agora atenção, até aqui estamos apenas falando de autenticação!
Mesmo que esse conceito tenha trazido a possibilidade de autenticação de usuários dentro do mesmo domínio, ou rede, hoje temos a possibilidade de também utilizar o mesmo conceito para validar usuários cross-domains, ou seja, a possibilidade de usar um usuário autenticado em um domínio em outro domínio.
Não quero entrar em muitos detalhes aqui, mas entenda, tem muito mais a ser estudado ao tratarmos do conceito de Federated Identity, e eu sugiro que você busque mais informações e dois bons documentos que podem ajudar nisso são o NIST 800-63C e o NISTIR 8149.
Vamos seguir e falar um pouco mais sobre o tema do artigo.
SAML
Basicamente podemos explicar o SAML ou Security Assertion Markup Language como um padrão que foi criado com um propósito bem claro de atender a necessidade de permitir o cross-domain single sign-on (SSO). Explicando de outra forma, isso permite que um usuário já autenticado em um sistema, possa ser autenticado em outro sistema, provando que já está autenticado em outro sistema, e o sistema que deseja autenticar o usuário confie no sistema que o autenticou anteriormente.
O conceito e uso do SAML não é novo, está entre os desenvolvedores e sistemas desde 2005, portanto um padrão já maduro e testado.
Atualmente em sua versão 2 (SAMLv2), é extremamente usado e tem um uso ainda mais evidente quando tratamos de sistemas de empresas e Governos. De forma bem básica, o que temos é o XML para representar a identidade digital do usuário e o protocolo HTTP como mecanismo de transporte destas informações.
Vamos entender um pouco como o SAML funciona.
Como já comentamos mais acima, o SAML é um protocolo de autenticação baseado em XML, onde um provedor de identidade armazena e valida as credenciais de um usuário. Essa identidade digital validada é então usada para autenticar o usuário em outros sistemas.
Nessa estrutura temos alguns “personagens” como o SP ou Service Provider que é o provedor do serviço que o user está tentando acesso. Além dele temos o RP ou Relying Party que é o serviço dentro do SP que está solicitando e recebendo os dados que estão no IdP (Identity Provider).
Se ficou um pouco complicado o exemplo, imagina que você está fazendo uma viagem internacional e quando você chega no país de destino, você precisa apresentar o seu passaporte, que será validado para permitir o seu acesso. Acho que assim fica mais fácil, não é?
Quais são os benefícios do SAML?
Bom, com certeza eu vou deixar passar algum, mas vamos aos que consigo pensar neste momento.
Acredito que o primeiro seja a comodidade para o usuário, pois permite que ele realize apenas um processo de autenticação e possa usar outros sistemas. Com isso, me vem logo à cabeça o segundo benefício que é claramente um aumento na segurança do processo de autenticação, pois evita que a credencial do usuário seja levada para muitos pontos.
Um outro benefício é que, sendo um padrão, facilita a ação dos desenvolvedores que podem agora entender apenas um único conceito de autenticação, e de quebra conseguir mais um benefício a possibilidade de conformidade com padrões exigidos.
Certeza que esqueci algum benefício, e seria bem legal se você puder colocar aí nos comentários.
Bom, acredito que agora podemos partir para o segundo tema, OAuth.
OAuth2
Em 2012 o modelo OAuth2.0 padronizou-se de fato na indústria, e assim, como os anteriores, o padrão OAuth é usado no momento em que um usuário ou mesmo um sistema precisa ter acesso a algum recurso. Então, desta forma o OAuth2.0 é um padrão que permite a um usuário ou sistema ganhar permissão para executar atividades em outro sistema.
Como já colocamos mais acima, o OAuth é um padrão de autorização e não um padrão de autenticação.
O OAuth2 usa os Access Tokens, que são dados que representam as informações de autorização para acesso ao recurso. Na documentação do OAuth2 não há uma definição de um padrão específico de um formato do Access Token, no entanto não é incomum vermos o JSON Web Token (JWT) sendo usado.
É importante que a gente conheça algumas (ou quem sabe todas) as funções presentes no OAuth2, então resolvi colocar algumas aqui.
O Resource Owner pode ou não dar permissão para usar o recurso que se deseja acesso. Quando você quer usar um recurso, é nesta função que estará indicado a quem pedir essa autorização. Por consequência, é normal que o nome da função que solicita o acesso, que pede a autorização, seja Client.
O Authorization Server, recebe uma solicitação do Client e emite o Access Token para o mesmo Client, desde que esse esteja devidamente autenticado pelo Rource Owner. Por último falaremos do Resource Server que basicamente é o responsável por proteger os recursos do usuário e é o que recebe as solicitações e valida um token dos Clients, e se tudo estiver certo, ele retorna os recursos apropriados para o Client.
Se ficou complicado, tem uma imagem abaixo para ajudar 🙂
Acredito que agora ficou bom e o entendimento mais fácil, certo?Legal, mas tem um ponto que é bem importante e ainda não falamos, o OAuth2.0 Scope. Ele é responsável por entregar ao Authorization Server os motivos que devem levar à autorização ou a concessão da permissão de acesso. Tá ok, entendi, mas o que é o Scope?
Bom, o Scope é a identificação de quais recursos o Client está tentando acesso, é apenas a forma como temos que identificar ao que temos que conceder a permissão, e isso depende muito do Resource Server.
Bem, acho que o básico conseguimos entregar neste artigo, mas há ainda muito mais que isso, o que falamos aqui são apenas conteúdos bem superficiais, tem muito documento importante e interessante para estudarmos, e neles o conteúdo é bem mais detalhado, é só buscar.
Como sempre, qualquer coisa que queira compartilhar ou perguntar deixa aí nos comentários. Se eu souber vou respondendo, se não souber vou buscar e compartilho.
Até a próxima!
