SSO iniciado por IdP vs SSO iniciado por SP#

Terminologia#

• Identity Provider (IdP): O serviço que armazena e autentica as identidades dos usuários.
• Service Provider (SP): Um site ou serviço que fornece serviços aos usuários.
• Single Sign-On (SSO): Um serviço de autenticação de sessão e usuário que permite que um usuário use um conjunto de credenciais de login (por exemplo, nome e senha) para acessar várias aplicações.
• SAML: Security Assertion Markup Language é um padrão aberto para troca de dados de autenticação e autorização entre partes, em particular, entre um provedor de identidade e um provedor de serviço. É um protocolo comumente usado para SSO. Quando um usuário é autenticado com sucesso pelo IdP, o IdP envia uma asserção SAML para o SP, que o SP valida e concede acesso ao usuário.
• OIDC: OpenID Connect é um protocolo mais moderno e seguro para SSO. É construído sobre o OAuth 2.0 e fornece uma maneira de verificar a identidade do usuário com base na autenticação realizada pelo IdP. Quando um usuário é autenticado com sucesso pelo IdP, o IdP envia um token formatado em JWT para o SP, que o SP valida e concede acesso ao usuário.

SSO iniciado por SP#

Como o nome sugere, o SSO iniciado por SP é iniciado pelo provedor de serviço. O usuário inicia o processo de autenticação acessando um recurso no site do SP. O SP então redireciona o usuário para o IdP para autenticação. Quando o usuário é autenticado, o IdP gera um token (OIDC) ou uma asserção SAML (SAML) e o envia de volta para o SP. O SP valida o token ou a asserção e concede acesso ao usuário.

1. O usuário visita o site do SP e tenta acessar um recurso.
2. O usuário clica no botão de login do provedor de SSO (por exemplo, Google, Azure AD, Okta, etc).
3. O SP redireciona o usuário para o IdP para autenticação.
4. O usuário faz login no IdP.
5. O IdP envia um token ou asserção de volta para o SP.
6. O SP valida o token ou a asserção e concede acesso ao usuário.

SSO iniciado por IdP#

Ao contrário do SSO iniciado por SP, o SSO iniciado por IdP é iniciado pelo provedor de identidade. O usuário inicia o processo de autenticação a partir do site do IdP. Normalmente, o usuário encontrará uma lista de aplicações SP suportadas no portal do IdP. O usuário clica na aplicação SP e é redirecionado para o site do SP com uma identidade pré-autenticada.

1. O usuário faz login no IdP.
2. O usuário visita o portal do IdP e seleciona uma aplicação SP.
3. O IdP valida a sessão atual do usuário e redireciona o usuário para o SP com uma identidade de SSO pré-autenticada.
4. O SP valida a identidade de SSO e concede acesso ao usuário.

SSO iniciado por IdP vs SSO iniciado por SP#

Vantagens do SSO iniciado por IdP em comparação com o SSO iniciado por SP#

O SSO iniciado por IdP é mais adotado por grandes empresas e organizações que dependem de vários aplicativos ou serviços de terceiros. Como Workday, Salesforce, etc. Ele fornece uma maneira centralizada de gerenciar o acesso dos usuários a várias aplicações e impor autenticações SSO. Ao habilitar o SSO iniciado por IdP, os funcionários podem acessar diretamente as aplicações conectadas pelo portal do IdP sem a necessidade de visitar o site de cada aplicação. Reduzindo o tempo de integração e melhorando a experiência do usuário.

Riscos do SSO iniciado por IdP em comparação com o SSO iniciado por SP#

O SSO iniciado por IdP apresenta mais riscos em comparação com o SSO iniciado por SP.

1. Falta de contexto de autenticação: Todas as solicitações de autenticação iniciadas pelo IdP são não solicitadas. Assim, o SP iniciou o processo de autenticação, potencialmente abrindo a porta para acesso não autorizado. Existe o risco de que a sessão do usuário possa ser sequestrada. Um agente malicioso poderia iniciar o processo de login para um usuário legítimo sem o seu conhecimento ou consentimento.

2. Fixação de sessão: Como o SP não inicia o processo de autenticação, a sessão do usuário pode ser fixa à sessão do IdP. Isso poderia levar a ataques de fixação de sessão onde um atacante poderia fixar a sessão do usuário à sessão do IdP e obter acesso não autorizado à conta do usuário.

3. Ataques de phishing: O SSO iniciado por IdP pode ser vulnerável a ataques de phishing. Um agente malicioso poderia enganar o usuário para visitar um portal falso do IdP e roubar as credenciais do usuário. Assim que o usuário fizer login, o atacante poderia redirecionar o usuário para o SP com uma identidade pré-autenticada.

4. Nenhuma garantia na validação de solicitação: Em um SSO iniciado por SP, normalmente o SP incluirá as informações de segurança necessárias na solicitação para o IdP para manter a integridade da solicitação. Assim que o SP recebe a resposta de autenticação, ele validará essas informações para evitar quaisquer ataques CSRF. Por exemplo, o parâmetro state no OIDC e RelayState no SAML. No entanto, no SSO iniciado por IdP, o SP não inicia o processo de autenticação, portanto, o SP não tem garantia na validação da solicitação.

Limitações do SSO iniciado por IdP em comparação com o SSO iniciado por SP#

O SSO iniciado por IdP não é suportado pelo OIDC devido às vulnerabilidades acima. O OIDC requer que o SP inicie o processo de autenticação para garantir a integridade da solicitação. Mesmo em casos onde os usuários iniciam o processo de autenticação a partir de um terceiro que não é o SP, o usuário deve ser primeiro direcionado ao SP para iniciar o processo de autenticação.

Mas no SAML, o SSO iniciado por IdP é possível. O IdP pode gerar uma asserção SAML sem o SP iniciar o processo de autenticação. Em um SAML IdP iniciado, uma asserção SAML sem um RequestID e RelayState adequados poderia ser enviada diretamente para o URL ACS do SP. O SP deve poder lidar com este tipo de asserção e conceder acesso ao usuário. (Nota: Sem o RequestID e RelayState, o SP não tem garantia sobre a integridade da solicitação).

Conclusão#

Embora o SSO iniciado por IdP forneça uma maneira centralizada de gerenciar o acesso dos usuários a várias aplicações, ele apresenta mais riscos em comparação com o SSO iniciado por SP. O SSO iniciado por SP é mais seguro e oferece mais garantias sobre a integridade da solicitação de autenticação. Recomenda-se o uso de SSO iniciado por SP para SSO baseado em OIDC e SAML.