Single Sign On (SSO): Considerações sobre autenticação única

Single Sign On (SSO): Considerações sobre autenticação única

- 6 mins

O trabalho de um analista de sistemas - e aqui também incluo os desenvolvedores - é, em sua essência, prover soluções através de tecnologias. E uma das questões mais comuns com que lidamos é a autenticação de usuários.

A autenticação é o processo de verificar a identidade de um usuário, ou seja, garantir que a pessoa que está acessando um sistema é realmente quem ela diz ser. E, para isso, é necessário que o usuário forneça suas credenciais de acesso, como um nome de usuário e senha.

Entretanto, para o usuário final dos sistemas desenvolvidos e projetados por nós, guardar ou memorizar várias credenciais para acessar diferentes sistemas é um grande incômodo. Nesse cenário, a implementação de um mecanismo de Single Sign On (SSO) pode ser uma boa solução para agradar gregos e troianos.

O que é o Single Sign On?

O Single Sign On (SSO) é um mecanismo que permite ao usuário acessar vários sistemas e serviços com uma única credencial de acesso, permitindo também um controle centralizado das credenciais de acesso em um ambiente.

O SSO é uma solução muito comum em organizações que possuem vários sistemas internos e até mesmo externos que precisam ser acessados por seus funcionários, parceiros e clientes.

Usuário com Single Sign On vs Usuário sem Single Sign On

Ilustração sobre a utilização do Single Sign On na prática

Algumas implementações de SSO dispensam até mesmo o processo de autenticação, como por exemplo em dispositivos que pertencem a um domínio de uma organização através de tecnologias como o Microsoft Active Directory (AD), onde o usuário necessita apenas autenticar-se no computador para iniciar sessão em outros serviços como e-mail e sistemas web.

Vantagens do Single Sign On

O Single Sign On traz várias vantagens para usuários e administradores de sistemas, tais como:

Facilidade de uso

Os usuários da organização precisam memorizar apenas uma credencial para acessar todos os sistemas integrados ao mecanismo de SSO. Essa centralização reduz a carga de lembrar várias senhas, facilitando o acesso e diminuindo drasticamente solicitações de redefinição de senha.

Com o passar dos anos, percebi o porquê desenvolvedores mais experientes dizem que tudo é um trade-off.

Trade-off é um termo que se refere a situações em que perdemos alguma(as) coisa(as), mas há compensação em outra(as).

Neste caso você ganha comodidade para o usuário, mas pode acabar abrindo mão de controle e segurança em casos onde a credencial possua senha de acesso fraca, ou até mesmo vazamentos.

Comentarei adiante como mitigar esses riscos.

Segurança

Implementar um mecanismo de SSO significa também centralizar a autenticação e, possivelmente, a autorização dos usuários, facilitando a gestão de permissões e o controle de acesso aos serviços.

Embora sejam conceitos muitas vezes correlatos e confundidos, autenticação e autorização são conceitos distintos. Enquanto autenticação é o processo de verificar se um ator é de fato quem ele diz ser, através de suas credenciais, a autorização é o processo de verificar se um usuário tem permissão para acessar um recurso ou funcionalidade específica, o que futuramente será abordado em outra publicação.

Outra possibilidade bem útil trazida pela implementação de mecanismos de SSO é a de desativar ou reativar usuários em diversos serviços de forma centralizada. Algum colaborador foi desligado da organização? Basta desativá-lo no domínio e os acessos serão automaticamente revogados. Obviamente que este último ponto pressupõe uma correta implementação.

Integração

O SSO facilita a integração entre sistemas, pois todos eles compartilham a mesma base de usuários e credenciais. Isso permite que os sistemas troquem informações de forma mais eficiente e segura, sem a necessidade de implementar autenticação e autorização em cada sistema individualmente.

Em termos práticos, ao autenticar-se em um serviço como o Microsoft AD, o usuário também estará autenticado em diversos outros serviços como e-mail (plataforma Microsoft Exchange), Teams entre outros.

Outro bom exemplo são os serviços oferecidos pelo Google. Com uma única conta você possui acesso a diversos serviços como GMail, Meet, Agenda, Drive entre outros.

Mas nem tudo são flores…

Apesar de suas vantagens, o Single Sign On também traz alguns perigos que devem ser considerados, tais como:

Risco de segurança

Alguns tópicos acima, quando falava sobre Facilidade de uso, comentei que estaremos fazendo um trade-off ao implementar mecanismo de SSO. Isso se dá ao fato de que, se as credenciais de acesso forem comprometidas, o invasor terá acesso a todos os sistemas que fazem parte do ambiente de autenticação.

Com relação a isso, é possível mitigar o risco utilizando autenticação de dois fatores e aplicando o princípio do menor privilégio, onde o usuário só deve ter acesso aos privilégios realmente necessários para exercer suas funções. Não apenas isso é suficiente; revisões periódicas desses privilégios garantem que os usuários acessem apenas o que realmente precisam.

Outro ponto a ser levado em consideração para minimizar as chances de problemas é a adoção de uma política de senhas robusta. Embora seja outro trade-off, pois requer que os usuários adotem senhas mais complexas e as alterem com certa periodicidade, este é um alicerce fundamental para qualquer organização quando se fala em segurança da informação.

Falhas de implementação

A implementação do SSO pode ser complexa e requerer um bom planejamento e conhecimento técnico. Falhas na implementação podem comprometer a segurança e a integridade dos sistemas.

É importante manter alinhado de forma clara e objetiva como o fluxo de autenticação deve acontecer. Digo isso por experiência própria.

Embora pareça óbvio, já me vi em situações onde foi necessário pontuar que um usuário desativado não deveria conseguir autenticar em aplicações. Talvez sua organização tenha regras de negócio específicas para algumas aplicações ou serviços.

Dependência de terceiros

O SSO geralmente depende de um provedor de identidade externo, como o já citado Microsoft AD, que é uma implementação do protocolo LDAP. Se o provedor de identidade sofrer uma falha ou ficar fora do ar, todos os sistemas que dependem dele também ficarão inacessíveis.

Uma possibilidade de mitigação deste risco seria permitir a autenticação local em caso de falha do provedor de identidade. Isso ocorreria através da importação das credenciais do usuário para base local da aplicação. Mais uma vez, temos um trade-off. Em alguns casos vale mais a pena deixar uma aplicação específica inacessível mesmo.

Conclusão

O Single Sign On (SSO) é uma solução poderosa que simplifica a experiência do usuário e facilita a administração de sistemas em ambientes corporativos, promovendo conveniência e centralização no gerenciamento de credenciais. Contudo, como toda solução tecnológica, o SSO não é isento de desafios. Implementá-lo requer planejamento cuidadoso e uma estratégia de segurança robusta para mitigar riscos, como o comprometimento de credenciais e a dependência de provedores externos.

Ao avaliar o uso do SSO, é essencial considerar os trade-offs envolvidos e balancear conveniência com segurança. Medidas como autenticação de dois fatores, políticas de senha robustas e o princípio do menor privilégio são fundamentais para proteger os sistemas e os dados da organização. Além disso, revisar periodicamente a implementação e os privilégios dos usuários é uma prática indispensável.

Embora não seja uma solução universal, o SSO destaca-se como um recurso valioso para organizações que desejam otimizar o acesso aos seus sistemas sem comprometer a segurança, desde que bem implementado. Avalie cuidadosamente as necessidades da sua organização e as melhores práticas de mercado antes de adotar esse mecanismo, e tenha em mente que as tecnologias (linguagens de programação e frameworks) nas quais você trabalha atualmente, muito provavelmente possuem mecanismos para facilitar essa implementação, o que exige uma boa pesquisa.

Matheus Martins

Matheus Martins

Desenvolvedor de Software Full Stack

comments powered by Disqus