Como funciona o oauth de duas pernas em OAuth 2.0?

Question

Como funciona o oauth de duas pernas em OAuth 2.0?

em OAuth 1.0, 2 pernas é muito fácil: basta enviar o pedido como de costume e omitir o cabeçalho access_token.

[[3]As coisas parecem ter mudado em OAuth 2.0 (drasticamente ,como descobri hoje:)). In OAuth 2.0, the request no longer has headers such as the nonce, consumer key, timestamp etc. Este é substituído por:

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh

eu entendo como 3 autorizações legged funcionam em OAuth 2.0 e a aplicação flui. Mas como funciona o 2-legged em 2.0? É possível conceber um API que suporta OAuth 2.0 de duas e três pernas?

Tenho andado à procura de informações sobre isto, mas tenho encontrado muitas coisas no 2-legged por 1.0 e quase nada para 2.0.

46

oauth-2.0 2-legged

Author: F21, 2013-01-10

Source

2 answers

Você também pode verificar a implementação do Google de 2-legged OAuth2 (creio que esta documentação foi publicada apenas recentemente).

A delegação do Google Drive SDK docs também deve ajudar a compreender a implementação do OAuth2 de 2 pernas do Google.

1

Author: Miguel Andres, 2014-03-20 19:23:59

score 61 · Accepted Answer

Depois de muita pesquisa, descobri que o tipo de subvenção é para este cenário. Uma vez que você introduz este termo no google, você pode encontrar muitos recursos muito úteis.

Este é o fluxo normal para o OAuth 2.0 de 3 pernas (queremos que o utilizador assine):

Suponha que temos os seguintes Pontos finais na nossa aplicação para Autenticação:

/oauth/auth

/oauth/token

([18]} normalmente (para a concessão do código de autorização), direcionamos o utilizador para /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

Então, após a autenticação, o utilizador é redireccionado para mysite.com/blah?code=somecode

E trocamo - lo por um símbolo usando /oauth/token?code=somecode&client_id=myid&client_secret=mysecret Podemos usar a ficha para fazer chamadas.

Este é o fluxo de aplicação para {[3] } para implementar OAuth 2-legged 2.0, que é marcadamente mais simples:

Publicamos simplesmente /oauth/token com os seguintes dados da forma:
```
grant_type=client_credentials&scope=view_friends
```

Note que o âmbito de aplicação é facultativo. Extremidade em seguida, retorna diretamente um token de Acesso para nós usar (nenhum token de atualização é fornecido). Uma vez que não é fornecido Nenhum token refresh, quando o token expirar, você terá que reautorizar e pedir um novo token.

Isto leva às seguintes advertências:

Use isto apenas para (muito) aplicações confiáveis, tais como aplicações internas.

do RFC

Outra solução é usar o JWT (tokens web JSON) como o google OAuth API. É um processo muito complicado, mas existem inúmeras bibliotecas para gerar seu JWT. Você então postou os seguintes dados do formulário (url codificado, é claro):

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt

Isto está postado em /oauth/token para obter o seu token.

Quanto à questão de se você pode criar uma API que suporta OAuth de 2 pernas e 3 pernas 2.0, sim, é. possível.

Então /auth o endpoint só é utilizado quando os utilizadores precisam de se autenticar contra o serviço.

No parâmetro /token, basta verificar o valor de grant_type nos parâmetros GET para urn:ietf:params:oauth:grant-type:jwt-bearer se usar JWT ou client_credentials para os potenciais clientes.

Lembre-se que ao gerar o client_id e o client_secret para dar ao utilizador, se estiver a suportar vários grant_types, certifique-se que tem uma coluna de base de dados para guardar o tipo de subvenção que o id e o secret foram gerar. Se necessário para ter vários tipos de subvenção por usuário, gerar um conjunto diferente de credenciais para cada tipo de subvenção.