OAuth 2.0 possui vários fluxos de trabalho. Eu tenho algumas perguntas sobre os dois.

1. Fluxo do código de autorização - O usuário efetua login no aplicativo cliente, o servidor de autorização retorna um código de autorização para o aplicativo. O aplicativo troca o código de autorização pelo token de acesso.
2. Fluxo de concessão implícito - O usuário efetua login no aplicativo cliente, o servidor de autorização emite um token de acesso diretamente ao aplicativo cliente.

Qual é a diferença entre as duas abordagens em termos de segurança? Qual é o mais seguro e por quê?

Não vejo uma razão pela qual uma etapa extra (código de autorização de troca de token) seja adicionada em um fluxo de trabalho quando o servidor puder emitir diretamente um token do Access.

Sites diferentes dizem que o fluxo do código de autorização é usado quando o aplicativo cliente pode manter as credenciais seguras. Por quê?

O access_tokené o que você precisa chamar um recurso protegido (uma API). No fluxo do Código de autorização, existem 2 etapas para obtê-lo:

1. O usuário deve autenticar e retornar codea ao consumidor da API (chamado de "Cliente").
2. O "cliente" da API (geralmente seu servidor da web) troca o codeobtido no nº 1 por um access_token, autenticando-se com um client_ideclient_secret
3. Em seguida, ele pode chamar a API com o access_token.

Portanto, há uma verificação dupla: o usuário que possui os recursos apareceu através de uma API e o cliente usando a API (por exemplo, um aplicativo Web). Ambos são validados para o acesso a ser concedido. Observe a natureza de "autorização" do OAuth aqui: o usuário concede acesso a seu recurso (por meio do coderetorno após a autenticação) a um aplicativo, o aplicativo recebe um access_tokene chama em nome do usuário.

No fluxo implícito, a etapa 2 é omitida. Portanto, após a autenticação do usuário, um access_tokené retornado diretamente, que você pode usar para acessar o recurso. A API não sabe quem está chamando essa API. Qualquer pessoa com a access_tokenlata, enquanto no exemplo anterior apenas o aplicativo da web (normalmente não é acessível internamente a ninguém).

O fluxo implícito é geralmente usado em cenários em que o armazenamento client ide client secretnão é recomendado (um dispositivo, por exemplo, embora muitos o façam de qualquer maneira). É isso que o aviso significa. As pessoas têm acesso ao código do cliente e, portanto, podem obter as credenciais e fingir se tornar clientes de recursos. No fluxo implícito, todos os dados são voláteis e não há nada armazenado no aplicativo.

Vou acrescentar aqui algo que não acho claro nas respostas acima:

• O fluxo de código de autorização permite que o token de acesso final nunca chegue e nunca seja armazenado na máquina com o navegador / aplicativo . O código de autorização temporário é fornecido à máquina com o navegador / aplicativo, que é então enviado para um servidor. O servidor pode trocá-lo com um token de acesso completo e ter acesso a APIs etc. O usuário com o navegador obtém acesso à API somente através do servidor com o token.
• O fluxo implícito pode envolver apenas duas partes e o token de acesso final é armazenado no cliente com o navegador / aplicativo. Se esse navegador / aplicativo estiver comprometido, o token de autenticação também será perigoso, o que pode ser perigoso.

tl; dr não usar fluxo implícita se você não confiar na máquina de usuários fichas de espera, mas você fazer confiar em seus próprios servidores.

A diferença entre ambos é que:

1. No fluxo implícito, o token é retornado diretamente via URL de redirecionamento com o sinal "#" e é usado principalmente em clientes javascript ou aplicativos móveis que não possuem servidor próprio, e o cliente não precisa fornecer seu segredo em algumas implementações .

2. No fluxo de código de autorização, o código é retornado com "?" Para ser legível pelo servidor, o servidor deve fornecer o segredo do cliente dessa vez para obter o token url para obter o token como objeto json do servidor de autorização. É usado no caso de você ter um servidor de aplicativos que pode lidar com isso e armazenar o token do usuário com seu perfil em seu próprio sistema e usado principalmente para aplicativos móveis comuns.

portanto, depende da natureza do aplicativo cliente, qual é o "código de autorização" mais seguro, pois ele solicita que o segredo no cliente e o token possam ser enviados entre o servidor de autorização e o aplicativo cliente em uma conexão muito segura, e o provedor de autorização pode restringir alguns clientes a usar apenas "Código de autorização" e desabilitar o Implicit

A concessão implícita é semelhante à concessão do código de autorização com duas diferenças distintas.

Ele se destina a ser usado por clientes baseados em agentes de usuários (por exemplo, aplicativos da web de página única) que não podem manter um segredo do cliente, porque todo o código e armazenamento do aplicativo é facilmente acessível.

Em segundo lugar, em vez de o servidor de autorização retornar um código de autorização que é trocado por um token de acesso, o servidor de autorização retorna um token de acesso.

Encontre detalhes aqui http://oauth2.thephpleague.com/authorization-server/which-grant/

Fluxo implícito

Vantagens

• Mais simples de implementar

Desvantagens

• Tokens de acesso visíveis para o navegador
• A origem dos tokens de acesso não pode ser determinada
• Os tokens de acesso não podem expirar (pela política do Google)

Fluxo do código de autorização

Vantagens

• Mais seguro
• Os tokens de acesso e os tokens de atualização podem ser criados apenas se um segredo compartilhado for conhecido
• Pode ser aprimorado com novos recursos de segurança e UX quando eles estiverem disponíveis

Desvantagens

• Deve implementar vários pontos de extremidade de autenticação

Citação: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

Deixe-me resumir os pontos que aprendi nas respostas acima e acrescentar alguns dos meus próprios entendimentos.

Fluxo do código de autorização !!!

• Se você tiver um servidor de aplicativos da web que atue como cliente OAuth
• Se você deseja ter acesso de longa duração
• Se você deseja ter acesso offline aos dados
• quando você é responsável pelas chamadas da API que seu aplicativo faz
• Se você não deseja vazar seu token OAuth
• Se você não deseja que seu aplicativo execute o fluxo de autorização sempre que precisar acessar os dados. NOTA: O fluxo de concessão implícita não recebe o token de atualização; portanto, se o servidor de autorização expirar os tokens de acesso regularmente, seu aplicativo precisará executar o fluxo de autorização sempre que precisar acessar.

Fluxo implícito de subvenção !!!

• Quando você não possui o Servidor de Aplicativos Web para atuar como Cliente OAuth
• Se você não precisar de acesso de longa duração, ou seja, é necessário apenas acesso temporário aos dados.
• Se você confiar no navegador onde o aplicativo é executado e houver uma preocupação limitada de que o token de acesso vaze para usuários não confiáveis.

Qual é o mais seguro e por quê?

Ambos são seguros, depende do ambiente em que você está usando.

Não vejo uma razão pela qual uma etapa extra (código de autorização de troca de token) seja adicionada em um fluxo de trabalho quando o servidor puder emitir diretamente um token do Access.

É simples Seu cliente não é seguro. Vamos ver em detalhes.

Considere que você está desenvolvendo um aplicativo Instagram APIe registre seu aplicativo Instagrame defina o que API'sprecisa. Instagramirá fornecer client_ideclient_secrect

No seu site, você configura um link que diz. "Venha usar meu aplicativo". Ao clicar nele, seu aplicativo da web deve fazer duas chamadas Instagram API.

Firstenvie uma solicitação para Instagram Authentication Servercom os parâmetros abaixo.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

Você não enviaclient_secret , não pode confiar no cliente (o usuário e ou o navegador dele que tentam usar seu aplicativo). O cliente pode ver o script url ou java e encontrá-lo client_secrectfacilmente. É por isso que você precisa de outro passo.

Você recebe um codee state. O codeaqui é temporarye não é salvo em nenhum lugar.

Em seguida, você faz uma secondchamada para Instagram API(do seu servidor)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

Como a chamada é feita em nosso servidor, podemos usar com segurança client_secret(o que mostra como estamos) com o codeque o usuário concedeu client_idpara usar o recurso.

Em resposta, teremos access_token

Do ponto de vista prático (o que eu entendi), o principal motivo para ter o fluxo de código Authz é:

1. Suporte para tokens de atualização (acesso de longo prazo por aplicativos em nome do Usuário), sem suporte implícito: consulte: https://tools.ietf.org/html/rfc6749#section-4.2
2. Suporte à página de consentimento, que é um local em que o Proprietário do recurso pode controlar qual acesso fornecer (tipo de página de permissões / autorização que você vê no google). O mesmo não está implícito. Consulte a seção: https://tools.ietf.org/html/rfc6749#section-4.1 , ponto (B)

"O servidor de autorização autentica o proprietário do recurso (por meio do agente do usuário) e estabelece se o proprietário do recurso concede ou nega a solicitação de acesso do cliente"

Além disso, usando tokens de atualização, os aplicativos podem obter acesso a longo prazo aos dados do usuário.

Parece haver dois pontos principais, não discutidos até o momento, que explicam por que o desvio no Tipo de Concessão do Código de Autorização adiciona segurança.

Resumindo : o tipo de concessão do código de autorização mantém informações confidenciais do histórico do navegador e a transmissão do token depende apenas da proteção HTTPS do servidor de autorização.

Versão mais longa:

A seguir, continuarei com a terminologia do OAuth 2 definida na RFC (é uma leitura rápida): servidor de recursos , cliente , servidor de autorização , proprietário do recurso .

Imagine que você deseja que um aplicativo de terceiros (= cliente) acesse determinados dados da sua conta do Google (= servidor de recursos). Vamos supor que o Google use o OAuth 2. Você é o proprietário do recurso da Conta do Google, mas agora opera o aplicativo de terceiros.

Primeiro, o cliente abre um navegador para enviar você para o URL seguro do servidor de autorização do Google. Em seguida, você aprova a solicitação de acesso e o servidor de autorização o envia de volta à URL de redirecionamento fornecida anteriormente pelo cliente, com o código de autorização na sequência de consultas. Agora, para os dois pontos principais:

1. O URL desse redirecionamento acaba no histórico do navegador . Portanto, não queremos um token de acesso diretamente útil e de longa duração aqui. O código de autorização de vida curta é menos perigoso na história. Note-se que o tipo Grant implícita não colocar o token na história.
2. A segurança desse redirecionamento depende do certificado HTTPS do cliente , não do certificado do Google. Portanto, obtemos a segurança de transmissão do cliente como um vetor de ataque extra (para que isso seja inevitável, o cliente precisa ser não JavaScript. Caso contrário, poderíamos transmitir o código de autorização via URL de fragmento, onde o código não passaria pela rede. Esse pode ser o motivo pelo qual o Implicit Grant Type, que usa um URL de fragmento, costumava ser recomendado para clientes JavaScript, mesmo que isso não ocorra mais.)

Com o Tipo de Concessão do Código de Autorização, o token é finalmente obtido por uma chamada do cliente para o servidor de autorização, em que a segurança da transmissão depende apenas do servidor de autorização , e não do cliente.