concessões de autorização OAuthv2

5

Acabei de ler este excelente tutorial sobre o OAuthv2 , mas ainda sinto falta de alguns conceitos importantes sobre concessões de autorização.

Basicamente, não entendo a necessidade dos dois ciclos de solicitação / resposta entre o aplicativo cliente e o servidor de autorização, onde:

  • Primeiro, o usuário é redirecionado para o servidor de autenticação durante uma Solicitação de autorização , em que (em uma autenticação bem-sucedida), ele recebe um código de autenticação ; e então
  • Em seguida, o aplicativo cliente faz uma segunda solicitação de token ao servidor de autenticação, onde o servidor de autenticação valida a ID, o segredo e o código de autenticação do cliente e envia de volta um token de acesso para usar

Códigos de autenticação vs. fichas de acesso

Qual é a diferença entre este "código de autenticação" e este "token de acesso"? Por que preciso primeiro gerar um código de autenticação para que eu possa, subsequentemente, obter um token de acesso?!? Por que não fazer tudo isso em uma viagem de ida e volta e obter um token de acesso após a autenticação bem-sucedida?

Tokens de acesso e servidores de recursos

Suponho que o ponto principal do token de acesso é atuar como um passe de sala para solicitações futuras, para que os aplicativos do cliente não sejam re-autenticando cada solicitação subseqüente. Por isso, suponho que, com um token de acesso válido, os aplicativos do cliente agora possam "falar diretamente" com os servidores de recursos. E suponho que, ao receber cada solicitação, os servidores de recursos provavelmente validem os tokens de acesso com seus respectivos servidores de autenticação. Estou no caminho certo aqui ou fora da base?

Tokens de acesso e SSO?

Os tokens de acesso podem ser usados em um cenário de SSO em que você tem vários servidores de recursos usando o mesmo servidor de autenticação? , uma vez que eu autentico com um servidor de autenticação e recebo meu token de acesso quando Estou dentro de 1 aplicativo SSO, posso migrar para outro aplicativo SSO e aplicar o mesmo token de acesso (assumindo que ele ainda não expirou) e estar "conectado" a esse segundo aplicativo, sem precisar autenticar novamente?

    
por smeeb 12.09.2015 / 05:22
fonte

1 resposta

1

Usar o subsídio do código de autorização oferece duas coisas que faltam a outros subsídios.

  1. fornece autenticação do usuário e do cliente. Ele faz a autenticação do cliente enviando o ID do cliente e o segredo do cliente ao adquirir o token de acesso.

  2. mantém o token de acesso oculto do agente do usuário (normalmente um navegador), onde eles podem ser roubados com muito mais facilidade.

O subsídio implícito realmente faz isso tudo em uma viagem de ida e volta e, portanto, expõe o token de acesso para o user-agent e não autentica o próprio cliente (somente o usuário).

Você está certo de que um cliente pode acessar os recursos no servidor de recursos usando o token de acesso sem autenticar novamente cada solicitação. O servidor de recursos não precisa se comunicar com o servidor de autorização para validar o token, pois ele usa assinaturas digitais para confiar no conteúdo de o token.

Os tokens de acesso podem ser usados em cenários de SSO, mas normalmente seu user-agent retornaria ao servidor de autorização para obter outro token de acesso para falar com outro servidor de recursos. Seu user-agent estabeleceria uma sessão (provavelmente cookies) com o servidor de autorização para evitar nova autenticação.

    
por 12.09.2015 / 20:17
fonte