SSO iniciado pelo IdP vs SSO iniciado pelo SP#

Terminologia#

• Provedor de Identidade (IdP): O serviço que armazena e autentica identidades de utilizadores.
• Provedor de Serviço (SP): Um serviço ou site que fornece serviços aos utilizadores.
• Single Sign-On (SSO): Um serviço de sessão e autenticação de utilizador que permite a um utilizador usar um único conjunto de credenciais de login (por exemplo, nome e senha) para aceder a várias aplicações.
• SAML: Security Assertion Markup Language é um padrão aberto para a 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 comum utilizado para SSO. Uma vez que um utilizador é autenticado com sucesso pelo IdP, o IdP envia uma asserção SAML para o SP, que o SP valida e concede acesso ao utilizador.
• 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 utilizador com base na autenticação realizada pelo IdP. Uma vez que um utilizador é autenticado com sucesso pelo IdP, o IdP envia um token no formato JWT para o SP, que o SP valida e concede acesso ao utilizador.

SSO iniciado pelo SP#

Como o nome sugere, o SSO iniciado pelo SP é iniciado pelo provedor de serviço. O utilizador inicia o processo de autenticação acedendo a um recurso no site do SP. O SP então redireciona o utilizador para o IdP para autenticação. Uma vez que o utilizador é 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 utilizador.

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

SSO iniciado pelo IdP#

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

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

SSO iniciado pelo IdP vs SSO iniciado pelo SP#

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

O SSO iniciado pelo IdP é mais adotado por grandes empresas e organizações que dependem de várias aplicações ou serviços de terceiros. Como Workday, Salesforce etc. Ele fornece uma maneira centralizada de gerir o acesso do utilizador a várias aplicações e aplicar autenticações SSO. Ao habilitar o SSO iniciado pelo IdP, os funcionários podem aceder diretamente às aplicações conectadas a partir do portal do IdP, sem precisar visitar o site de cada aplicação. Reduzindo o tempo de integração e melhorando a experiência do utilizador.

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

O SSO iniciado pelo IdP acarreta mais riscos em comparação com o SSO iniciado pelo 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 acessos não autorizados. Existe o risco de que a sessão do utilizador possa ser sequestrada. Um ator malicioso poderia iniciar o processo de login para um utilizador legítimo sem o conhecimento ou consentimento dele.

2. Fixação de sessão: Como o SP não inicia o processo de autenticação, a sessão do utilizador poderia ser fixada à sessão do IdP. Isso poderia levar a ataques de fixação de sessão em que um atacante poderia fixar a sessão do utilizador à sessão do IdP e obter acesso não autorizado à conta do utilizador.

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

4. Sem garantia na validação de solicitação: Em um SSO iniciado pelo SP, normalmente o SP inclui informações de segurança necessárias na solicitação ao IdP para manter a integridade da solicitação. Uma vez que o SP recebe a resposta de autenticação, ele valida essas informações para evitar quaisquer ataques CSRF. Exemplo: O parâmetro state em OIDC e RelayState em SAML. No entanto, em SSO iniciado pelo 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 pelo IdP em comparação com o SSO iniciado pelo SP#

O SSO iniciado pelo 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 utilizadores começam o processo de autenticação a partir de um terceiro que não seja o SP, o utilizador deve ser redirecionado primeiro para o SP para iniciar o processo de autenticação.

Mas no SAML, o SSO iniciado pelo IdP é possível. O IdP pode gerar uma asserção SAML sem que o SP inicie o processo de autenticação. Em um SAML IdP-iniciado SSO, uma asserção SAML sem um RequestID e RelayState adequados pode ser enviada diretamente para o URL ACS do SP. O SP deve ser capaz de lidar com esse tipo de asserção e conceder acesso ao utilizador. (Nota: Sem o RequestID e RelayState, o SP não tem garantia sobre a integridade da solicitação).

Conclusão#

Mesmo que o SSO iniciado pelo IdP forneça uma maneira centralizada de gerir o acesso do utilizador a várias aplicações, ele acarreta mais riscos em comparação com o SSO iniciado pelo SP. O SSO iniciado pelo SP é mais seguro e fornece mais garantias sobre a integridade da solicitação de autenticação. Recomenda-se o uso do SSO iniciado pelo SP tanto para SSO baseado em OIDC quanto em SAML.