Qual a diferença entre o OAuth 2 e o OAuth 1?

Em termos muito simples, alguém pode explicar a diferença entre o OAuth 2 e o OAuth 1?

O OAuth 1 está obsoleto agora? Deveríamos estar implementando o OAuth 2? Não vejo muitas implementações do OAuth 2; a maioria ainda usa o OAuth 1, o que me faz duvidar que o OAuth 2 esteja pronto para uso. É isso?

Eran Hammer-Lahav fez um excelente trabalho ao explicar a maioria das diferenças em seu artigo Introducing OAuth 2.0 . Para resumir, aqui estão as principais diferenças:

Mais fluxos de OAuth para permitir melhor suporte para aplicativos que não são baseados em navegador. Essa é uma das principais críticas ao OAuth de aplicativos clientes que não eram baseados em navegador. Por exemplo, no OAuth 1.0, aplicativos de desktop ou de celular precisavam direcionar o usuário a abrir o navegador para o serviço desejado, autenticar com o serviço e copiar o token do serviço de volta para o aplicativo. A principal crítica aqui é contra a experiência do usuário. Com o OAuth 2.0, agora existem novas maneiras de um aplicativo obter autorização para um usuário.

O OAuth 2.0 não exige mais que os aplicativos clientes tenham criptografia. Isso volta à antiga API de autenticação do Twitter, que não exigia o aplicativo para tokens de hash HMAC e seqüências de solicitação. Com o OAuth 2.0, o aplicativo pode fazer uma solicitação usando apenas o token emitido por HTTPS.

As assinaturas do OAuth 2.0 são muito menos complicadas. Chega de análise, classificação ou codificação especial.

Os tokens de acesso do OAuth 2.0 têm "vida curta".Normalmente, os tokens de acesso do OAuth 1.0 podem ser armazenados por um ano ou mais (o Twitter nunca os deixa expirar). OAuth 2.0 tem a noção de tokens de atualização. Embora eu não tenha muita certeza do que sejam, meu palpite é que seus tokens de acesso podem durar pouco (ou seja, com base na sessão), enquanto seus tokens de atualização podem ter "tempo de vida". Você usaria um token de atualização para adquirir um novo token de acesso, em vez de pedir ao usuário que re-autorize seu aplicativo.

Por fim, o OAuth 2.0 deve ter uma separação clara de funções entre o servidor responsável pelo tratamento de solicitações do OAuth e o servidor responsável pela autorização do usuário. Mais informações sobre isso estão detalhadas no artigo mencionado acima.

Vejo ótimas respostas aqui em cima, mas o que sinto falta são alguns diagramas e, como tive que trabalhar com o Spring Framework, deparei com a explicação deles .

Acho os seguintes diagramas muito úteis. Eles ilustram a diferença na comunicação entre as partes com OAuth2 e OAuth1.

OAuth 2

OAuth 1

As explicações anteriores são todas IMO excessivamente detalhadas e complicadas. Simplificando, o OAuth 2 delega a segurança ao protocolo HTTPS. O OAuth 1 não exigia isso e, consequentemente, tinha métodos alternativos para lidar com vários ataques. Esses métodos exigiram que o aplicativo se envolvesse em certos protocolos de segurança que são complicados e podem ser difíceis de implementar. Portanto, é mais simples confiar apenas no HTTPS para segurança, para que os desenvolvedores de aplicativos não precisem se preocupar com isso.

Quanto às suas outras perguntas, a resposta depende. Alguns serviços não desejam exigir o uso de HTTPS, foram desenvolvidos antes do OAuth 2 ou têm algum outro requisito que pode impedi-los de usar o OAuth 2. Além disso, houve muito debate sobre o próprio protocolo do OAuth 2. Como você pode ver, o Facebook, o Google e alguns outros têm versões ligeiramente diferentes dos protocolos implementados. Portanto, algumas pessoas aderem ao OAuth 1 porque ele é mais uniforme nas diferentes plataformas. Recentemente, o protocolo OAuth 2 foi finalizado, mas ainda precisamos ver como será sua adoção.

Observe que há sérios argumentos de segurança contra o uso do Oauth 2:

um artigo sombrio

e mais técnico

Observe que eles são provenientes do principal autor de Oauth 2.

Pontos chave:

• Oauth 2 não oferece segurança sobre o SSL, enquanto o Oauth 1 é independente de transporte.

• de certa forma, o SSL não é seguro, pois o servidor não verifica a conexão e as bibliotecas de clientes comuns facilitam a ignorar falhas.

  O problema com SSL / TLS é que, quando você falha ao verificar o certificado no lado do cliente, a conexão ainda funciona. Sempre que ignorar um erro leva ao sucesso, os desenvolvedores farão exatamente isso. O servidor não tem como impor a verificação de certificado e, mesmo que pudesse, um invasor certamente não o fará.

• você pode dedicar toda a sua segurança, o que é muito mais difícil de fazer no OAuth 1.0:

  O segundo problema potencial comum são erros de digitação. Você consideraria um design adequado ao omitir um caractere (os 's' em 'https') anula toda a segurança do token? Ou, talvez, enviando a solicitação (por uma conexão SSL / TLS válida e verificada) para o destino errado (diga ' http://gacebook.com '?). Lembre-se de que poder usar tokens de portador de OAuth na linha de comando era claramente um promotor de tokens de portador de caso de uso promovido.

A segurança do protocolo OAuth 1.0 ( RFC 5849 ) se baseia na suposição de que uma chave secreta incorporada em um aplicativo cliente pode ser mantida em sigilo. No entanto, a suposição é ingênua.

No OAuth 2.0 ( RFC 6749 ), um aplicativo cliente ingênuo é chamado de cliente confidencial . Por outro lado, um aplicativo cliente em um ambiente em que é difícil manter uma chave secreta em sigilo é chamado de cliente público . Veja 2.1. Tipos de cliente para obter detalhes.

Nesse sentido, o OAuth 1.0 é uma especificação apenas para clientes confidenciais.

" OAuth 2.0 e o caminho para o inferno " afirma que o OAuth 2.0 é menos seguro, mas não há diferença prática no nível de segurança entre os clientes do OAuth 1.0 e os clientes confidenciais do OAuth 2.0. O OAuth 1.0 requer computação de assinatura, mas não aumenta a segurança se já estiver garantido que uma chave secreta no lado do cliente possa ser mantida em sigilo. A assinatura de computação é apenas um cálculo complicado, sem qualquer aprimoramento prático da segurança. Quero dizer, comparado à simplicidade que um cliente OAuth 2.0 se conecta a um servidor via TLS e apenas apresenta client_ide client_secret, não se pode dizer que o cálculo complicado é melhor em termos de segurança.

Além disso, o RFC 5849 (OAuth 1.0) não menciona nada sobre redirecionadores abertos, enquanto o RFC 6749 (OAuth 2.0) faz. Ou seja, o oauth_callbackparâmetro do OAuth 1.0 pode se tornar uma falha de segurança.

Portanto, não acho que o OAuth 1.0 seja mais seguro que o OAuth 2.0.

A segurança do OAuth 1.0 depende do cálculo da assinatura. Uma assinatura é calculada usando uma chave secreta, na qual uma chave secreta é uma chave compartilhada para HMAC-SHA1 ( RFC 5849, 3.4.2 ) ou uma chave privada para RSA-SHA1 ( RFC 5849, 3.4.3 ). Qualquer pessoa que conhece a chave secreta pode calcular a assinatura. Portanto, se a chave secreta for comprometida, a complexidade do cálculo da assinatura não terá sentido, por mais complexa que seja.

Isso significa que a segurança do OAuth 1.0 não depende da complexidade e da lógica do cálculo de assinaturas, mas apenas da confidencialidade de uma chave secreta. Em outras palavras, o que é necessário para a segurança do OAuth 1.0 é apenas a condição de que uma chave secreta possa ser mantida em sigilo. Isso pode parecer extremo, mas o cálculo da assinatura não adiciona aprimoramento de segurança se a condição já estiver satisfeita.

Da mesma forma, os clientes confidenciais do OAuth 2.0 contam com a mesma condição. Se a condição já estiver satisfeita, há algum problema na criação de uma conexão segura usando TLS e no envio client_ide client_secretpara um servidor de autorização através da conexão segura? Existe alguma grande diferença no nível de segurança entre os clientes confidenciais do OAuth 1.0 e OAuth 2.0 se os dois confiarem na mesma condição?

Não consigo encontrar um bom motivo para o OAuth 1.0 culpar o OAuth 2.0. O fato é que (1) OAuth 1.0 é apenas uma especificação apenas para clientes confidenciais e (2) OAuth 2.0 simplificou o protocolo para clientes confidenciais e também para clientes públicos suportados . Independentemente de saber bem ou não, os aplicativos de smartphone são classificados como clientes públicos ( RFC 6749, 9 ), que se beneficiam do OAuth 2.0.

As assinaturas do OAuth 2.0 não são necessárias para as chamadas reais da API após a geração do token. Ele possui apenas um token de segurança.

O OAuth 1.0 exige que o cliente envie dois tokens de segurança para cada chamada da API e use os dois para gerar a assinatura. Exige que os pontos de extremidade dos recursos protegidos tenham acesso às credenciais do cliente para validar a solicitação.

Aqui descreve a diferença entre o OAuth 1.0 e 2.0 e como ambos funcionam.

Aparentemente, o OAuth 2 é um desperdício de tempo (da boca de alguém que está muito envolvido):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Ele diz (editado por questões de brevidade e negrito por ênfase):

... Não posso mais estar associado ao padrão OAuth 2.0. Renunciei ao cargo de autor e editor principal, retirei meu nome da especificação e saí do grupo de trabalho. Remover meu nome de um documento que trabalhei meticulosamente por três anos e mais de duas dúzias de rascunhos não foi fácil. Decidir seguir em frente de um esforço que liderei por mais de cinco anos foi angustiante.

... No final, cheguei à conclusão de que o OAuth 2.0 é um protocolo ruim. WS- * ruim. Já é ruim o suficiente que eu não queira mais me associar a ele. ... Quando comparada com o OAuth 1.0, a especificação 2.0 é mais complexa, menos interoperável, menos útil, mais incompleta e, o mais importante, menos segura.

Para ficar claro, o OAuth 2.0, ao lado de um desenvolvedor com profundo conhecimento de segurança na Web, provavelmente resultará em uma implementação segura. No entanto, nas mãos da maioria dos desenvolvedores - como tem sido a experiência dos últimos dois anos - é provável que o 2.0 produza implementações inseguras.

Se você precisar de alguma explicação avançada, leia as duas especificações:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Se você precisar de uma explicação clara das diferenças de fluxo, isso poderá ajudá-lo:

Fluxo OAuth 1.0

1. O aplicativo cliente é registrado com o provedor, como o Twitter.
2. O Twitter fornece ao cliente um "segredo do consumidor" exclusivo para esse aplicativo.
3. O aplicativo cliente assina todas as solicitações do OAuth no Twitter com seu "segredo do consumidor" exclusivo .
4. Se alguma solicitação do OAuth estiver malformada, com dados ausentes ou assinada incorretamente, a solicitação será rejeitada.

Fluxo OAuth 2.0

1. O aplicativo cliente é registrado com o provedor, como o Twitter.
2. O Twitter fornece ao cliente um "segredo do cliente" exclusivo para esse aplicativo.
3. O aplicativo cliente inclui "segredo do cliente" com cada solicitação geralmente como cabeçalho http.
4. Se alguma solicitação do OAuth estiver malformada, com dados ausentes ou contiver o segredo errado, a solicitação será rejeitada.

Fonte: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

O OAuth 2.0 promete simplificar as coisas das seguintes maneiras:

1. O SSL é necessário para todas as comunicações necessárias para gerar o token. Essa é uma enorme diminuição na complexidade, porque essas assinaturas complexas não são mais necessárias.
2. As assinaturas não são necessárias para as chamadas reais da API após a geração do token - o SSL também é altamente recomendado aqui.
3. Depois que o token foi gerado, o OAuth 1.0 exigiu que o cliente envie dois tokens de segurança a cada chamada da API e use os dois para gerar a assinatura. O OAuth 2.0 possui apenas um token de segurança e nenhuma assinatura é necessária.
4. É claramente especificado quais partes do protocolo são implementadas pelo "proprietário do recurso", que é o servidor real que implementa a API e quais partes podem ser implementadas por um "servidor de autorização" separado. Isso tornará mais fácil para produtos como o Apigee oferecer suporte ao OAuth 2.0 para APIs existentes.

Fonte: http://blog.apigee.com/detail/oauth_differences

Do ponto de vista da segurança, eu usaria o OAuth 1. Veja OAuth 2.0 e o caminho para o inferno

cite esse link: "Se você está atualmente usando 1.0 com êxito, ignore o 2.0. Ele não oferece um valor real acima de 1.0 (acho que seus desenvolvedores de clientes já descobriram assinaturas 1.0 até agora).

Se você é novo nesse espaço e se considera um especialista em segurança, use o 2.0 após um exame cuidadoso de seus recursos. Se você não é um especialista, use a 1.0 ou copie a implementação 2.0 de um provedor em que você confia para acertar (os documentos da API do Facebook são um bom ponto de partida). A versão 2.0 é melhor em larga escala, mas se você estiver executando uma operação importante, provavelmente terá alguns especialistas em segurança no local para descobrir tudo.