Supongamos que tenemos una API RESTful cuyos recursos queremos exponer. Los usuarios finales trabajarán con esta API a través de aplicaciones cliente como aplicaciones móviles y clientes basados en Javascript que se ejecutan en navegadores web.

Con OAuth 2.0, esta API RESTful se ubicará en el servidor de recursos y tendremos un servidor de autorización en el que se registrarán las aplicaciones cliente. Los usuarios se registrarán en el servidor de autorización y podrán otorgar permiso a esas aplicaciones para acceder a los recursos en su nombre o no.

Entonces, cuando el usuario accede a una aplicación cliente, será redirigido al Servidor de Autorización y se le pedirá que otorgue permisos a dicha aplicación cliente. Después de eso, se emite un token de acceso y el cliente puede realizar solicitudes al servidor de recursos.

Todo esto es bastante claro para mí. Solo falta una pieza: la protección de cada recurso puede depender del usuario. Para ser más precisos, podría depender de los reclamos. Lo que quiero decir con eso es que podemos tener la siguiente situación:

El recursohttp://resourceserver.com/api/first-resource solo debe ser accesible para los usuarios con el reclamo "ExampleClaim" con valor 123.

El recursohttp://resourceserver.com/api/second-resource solo debe ser accesible para los usuarios con el reclamo "AnotherClaim" con valor 123.

El recursohttp://resourceserver.com/api/third-resource debe ser accesible para cualquier usuario.

Cuando escuché por primera vez que OAuth estaba tratando con ASP.NET WebAPI y lo traté de la siguiente manera: cuando la solicitud se envió con elAuthorization: Bearer [token] encabezado, en el lado del servidor se configuró el subproceso principal y pensé que esto significaba que el usuario estaba autenticado con la API. Entonces solía[Authorize] atributos para verificar si el usuario puede acceder al recurso.

Después de estudiar OAuth más profundamente, vi que era un mal uso terrible del protocolo. Como he aprendido, OAuth autoriza aplicaciones y no usuarios. Cuando la solicitud se realiza con el encabezado Autorización, como he aprendido, el token de acceso no debe contener información sobre el usuario, solo sobre la aplicación a la que se le permite realizar la solicitud.

Teniendo en cuenta eso, enviar el encabezado de autorización con la solicitud no identifica al usuario y no dice si el usuario puede o no acceder a dicho recurso.

En ese caso, ¿cómo se realiza este tipo de autorización? Quiero decir, ¿no es la autorización de la aplicación cliente que realiza la solicitud, sino la autorización del usuario que accede al recurso en función de sus reclamos? Creo que aquí es donde OpenID Connect y sus tokens de identificación entran, pero no estoy seguro. ¿Cómo se maneja esto?