SSO

Em resumo

SSO é a sigla de single sign-on, login único. É o arranjo pelo qual uma pessoa se autentica uma vez perante um provedor de identidade e as demais aplicações aceitam o resultado dessa autenticação em vez de pedir credenciais novamente.

O que trafega entre os sistemas não é a senha. É uma declaração assinada de que alguém se autenticou, com qual método e quando. Essa declaração é todo o mecanismo.

Como se sustenta uma sessão que abre várias aplicações

Há três peças, e vale a pena nomeá-las separadamente, porque a maioria dos problemas de um SSO vive na relação entre elas.

• O provedor de identidade — o sistema que autentica a pessoa e emite a declaração. É o único que vê o fator de autenticação.
• A aplicação — o sistema que precisa saber quem entrou. Ele não autentica: valida a assinatura da declaração e confia no seu conteúdo.
• A sessão — o período durante o qual essa declaração continua sendo aceita sem repetir a autenticação. Define quanto dura o conforto e quanto dura o risco.

Os padrões que formalizam a troca são dois. O SAML 2.0 transporta declarações em XML e é o que predomina em ambientes corporativos com aplicações instaladas há anos. O OpenID Connect é uma camada de identidade construída sobre o OAuth 2.0 que transporta um token de identidade e é o que predomina em aplicações web e móveis novas.

O OAuth 2.0 não é um protocolo de autenticação

É a confusão mais frequente da categoria e produz integrações inseguras, então vale a pena esclarecer.

O OAuth 2.0 resolve delegação de autorização: permite que uma aplicação acesse um recurso em nome de uma pessoa, sem conhecer suas credenciais. Ele responde à pergunta do que um sistema pode fazer.

O OpenID Connect acrescenta a peça que falta: um token de identidade que declara quem é a pessoa e como ela se autenticou. Ele responde à pergunta de quem entrou.

Usar um token de acesso do OAuth como se fosse prova de identidade é tratar uma permissão como uma credencial. São coisas diferentes, e o padrão as separou de propósito.

O SSO reduz a quantidade de autenticações, não as fortalece

Um SSO bem implementado melhora a experiência e melhora o controle: há um único lugar onde se aplica a política de acesso, um único lugar onde se revoga e um único registro de quem entrou em quê.

Também concentra o risco, por definição. Se a autenticação do provedor de identidade depende de uma senha reutilizada, esse único ponto abre todo o portfólio de aplicações. É o que transforma um credential stuffing bem-sucedido contra o provedor de identidade em um incidente de alcance total, e não de uma única aplicação.

Daí a regra prática: o SSO é implementado junto com o MFA sobre o provedor de identidade, não no lugar dele. O conforto vem do SSO. A força vem do fator.

Duas decisões a mais que costumam ficar sem dono e decidem o resultado:

• Duração da sessão — uma sessão longa é confortável e também é uma janela longa para quem rouba um token. É o parâmetro que a autenticação adaptativa ajusta conforme o risco da operação, em vez de fixá-lo igual para tudo.
• Logout federado — encerrar a sessão em uma aplicação não encerra a sessão no provedor de identidade nem nas demais, a menos que o logout federado esteja implementado. Frequentemente não está.

O SSO corporativo e o login com redes sociais não são o mesmo arranjo

Os dois usam a mesma mecânica e atendem a interesses diferentes.

No SSO corporativo, a organização controla o provedor de identidade. Define a política, revoga o acesso quando alguém sai e conserva o registro.

No login com uma rede social ou uma conta de consumidor, o provedor de identidade é um terceiro com suas próprias regras. A organização delega a ele a qualidade da autenticação e, com ela, a qualidade do vínculo: herda um dado verificado por outro sem ver como foi verificado. Para uma identidade digital que depois precisa sustentar uma obrigação regulatória, essa herança não basta.