Suponha que tenhamos alguma API RESTful cujos recursos queremos expor. Os usuários finais trabalharão com essa API por meio de aplicativos clientes, como aplicativos móveis e clientes baseados em Javascript, executados em navegadores da web.

Com o OAuth 2.0, essa API RESTful fica no servidor de recursos e teremos um servidor de autorização no qual os aplicativos clientes estão registrados. Os usuários serão registrados no servidor de autorização e poderão conceder permissão para que esses aplicativos acessem recursos em seu nome ou não.

Portanto, quando o usuário acessar um aplicativo cliente, ele será redirecionado para o Servidor de Autorização e solicitado a conceder permissões para o aplicativo cliente. Depois disso, um token de acesso é emitido e o cliente pode fazer solicitações ao Servidor de Recursos.

Tudo isso está bem claro para mim. Há apenas uma peça que falta: a proteção de cada recurso pode depender do usuário. Para ser mais preciso, pode ser dependente de declarações. O que quero dizer com isso é que podemos ter a seguinte situação:

O recursohttp://resourceserver.com/api/first-resource só deve ser acessível a usuários com a reivindicação "ExampleClaim" com o valor 123.

O recursohttp://resourceserver.com/api/second-resource só deve ser acessível a usuários com reivindicação "AnotherClaim" com o valor 123.

O recursohttp://resourceserver.com/api/third-resource deve estar acessível a qualquer usuário.

Quando soube pela primeira vez que o OAuth estava lidando com o ASP.NET WebAPI, lidei com isso da seguinte maneira: quando a solicitação foi enviada com oAuthorization: Bearer [token] No lado do servidor, o principal do thread foi definido e eu pensei que isso significava que o usuário estava autenticado com a API. Então eu usei[Authorize] atributos para verificar se o usuário pode acessar o recurso.

Depois de estudar o OAuth mais profundamente, vi que esse era um uso indevido terrível do protocolo. Como aprendi, o OAuth autoriza aplicativos e não usuários. Quando a solicitação é feita com o cabeçalho de autorização, como aprendi, o token de acesso não deve conter informações sobre o usuário, apenas sobre o aplicativo que está autorizado a fazer a solicitação.

Considerando que, o envio do cabeçalho de autorização com a solicitação não identifica o usuário e não diz se o usuário pode ou não acessar o referido recurso.

Nesse caso, como se executa esse tipo de autorização? Quero dizer, não a autorização do aplicativo cliente que está executando a solicitação, mas a autorização do usuário acessando o recurso com base em suas reivindicações? Acredito que é aqui que entram o OpenID Connect e seus tokens de identificação, mas não tenho certeza. Como alguém gerencia isso?