tl; dr: Tudo isso por motivos de segurança.
O OAuth 2.0 queria atender a esses dois critérios:
- Você deseja permitir que os desenvolvedores usem URI de redirecionamento não HTTPS, porque nem todos os desenvolvedores têm um servidor habilitado para SSL e, se o fazem, ele nem sempre é configurado corretamente (certificados SSL confiáveis e não autoassinados, relógio do servidor sincronizado ...).
- Você não deseja que os hackers possam roubar acesso / atualizar tokens interceptando solicitações.
Detalhes abaixo:
O fluxo implícito só é possível em um ambiente de navegador por motivos de segurança:
No fluxo implícito, o token de acesso é passado diretamente como um fragmento de hash (não como um parâmetro de URL). Uma coisa importante sobre o fragmento de hash é que, depois de seguir um link que contém um fragmento de hash, apenas o navegador está ciente do fragmento de hash. Os navegadores passarão o fragmento de hash diretamente para a página da web de destino (o URI de redirecionamento / a página do cliente). Fragmento de hash tem as seguintes propriedades:
- Eles não fazem parte da solicitação HTTP, portanto, não podem ser lidos pelos servidores e, por isso, não podem ser interceptados por servidores / roteadores intermediários (isso é importante).
- Eles existem apenas no navegador - lado do cliente -, portanto, a única maneira de ler o fragmento de hash é usando JavaScript que é executado na página.
Isso torna possível transmitir um token de acesso diretamente ao cliente sem o risco de ser interceptado por um servidor intermediário. Isso tem a ressalva de ser possível apenas no lado do cliente e precisa de javascript executando o lado do cliente para usar o token de acesso.
O fluxo implícito também possui problemas de segurança que requerem mais lógica para solucionar / evitar, por exemplo:
- Um invasor pode obter um token de acesso de um usuário em um site / aplicativo diferente (digamos se ele é o proprietário do outro site / aplicativo), registrar o token em seu site e passá-lo como um parâmetro de URL no seu site portanto, representando o usuário em seu site. Para evitar isso, verifique o ID do cliente associado ao token de acesso (por exemplo, para o Google, você pode usar o ponto de extremidade tokeninfo) para garantir que o token tenha sido emitido com seu próprio ID de cliente (por exemplo, por seu próprio aplicativo) ou verifique a assinatura se você estiver usando um IDToken (mas isso requer o segredo do seu cliente).
- Se a solicitação de autenticação não se originou de sua própria propriedade (chamada ataques de fixação de sessão), para evitar isso, você deseja gerar um hash aleatório no seu site, salve-o em um cookie e passe o mesmo hash no parâmetro de URL do estado de a solicitação de autenticação, quando o usuário voltar, verifique o parâmetro state com o cookie e ele deverá corresponder.
No fluxo do código de autorização , não é possível transmitir um token de acesso diretamente em um parâmetro de URL, porque os parâmetros de URL fazem parte da Solicitação HTTP; portanto, qualquer servidor / roteador intermediário pelo qual sua solicitação passaria (poderia ser centenas) poderia leia o token de acesso se você não estiver usando uma conexão criptografada (HTTPS), permitindo o que é conhecido como ataques Man-in-the-middle.
Passar o token de acesso diretamente em um parâmetro de URL poderia, em teoria, ser possível, mas o servidor de autenticação teria que garantir que o URI de redirecionamento esteja usando HTTPS com criptografia TLS e um certificado SSL 'confiável' (normalmente de uma Autoridade de Certificação que não é gratuita) para garantir que o servidor de destino seja legítimo e que a solicitação HTTP esteja totalmente criptografada. Ter todos os desenvolvedores que compram um certificado SSL e configuram o SSL adequadamente em seu domínio seria uma grande dor e retardaria tremendamente a adoção. É por isso que é fornecido um "código de autorização" intermediário de uso único que apenas o destinatário legítimo poderá trocar (porque você precisa do segredo do cliente) e que o código será inútil para hackers em potencial que interceptem os pedidos em transações não criptografadas (porque eles não
Você também pode argumentar que o fluxo implícito é menos seguro; existem vetores de ataque em potencial, como falsificar o domínio durante o redirecionamento - por exemplo, seqüestrando o endereço IP do site do cliente. Esse é um dos motivos pelos quais o fluxo implícito concede apenas tokens de acesso (que deveriam ter um tempo de uso limitado) e nunca atualiza tokens (que são ilimitados no tempo). Para solucionar esse problema, recomendamos que você hospede suas páginas da Web em um servidor habilitado para HTTPS sempre que possível.