Предположим, у нас есть некоторый RESTful API, ресурсы которого мы хотим предоставить. Конечные пользователи будут работать с этим API через клиентские приложения, такие как мобильные приложения и клиенты на основе Javascript, которые работают в веб-браузерах.

В OAuth 2.0 этот RESTful API будет лежать на сервере ресурсов, и у нас будет один сервер авторизации, на котором будут зарегистрированы клиентские приложения. Затем пользователи будут зарегистрированы на сервере авторизации и смогут разрешать этим приложениям доступ к ресурсам от их имени или нет.

Поэтому, когда пользователь получает доступ к одному клиентскому приложению, он будет перенаправлен на сервер авторизации и получит приглашение предоставить разрешения для указанного клиентского приложения. После этого выдается токен доступа, и клиент может отправлять запросы на сервер ресурсов.

Все это совершенно ясно для меня. Здесь есть только один недостаток: защита каждого ресурса может зависеть от пользователя. Чтобы быть более точным, это может зависеть от требований. Я имею в виду, что у нас может быть следующая ситуация:

Ресурсhttp://resourceserver.com/api/first-resource должен быть доступен только пользователям с заявкой «ExampleClaim» со значением 123.

Ресурсhttp://resourceserver.com/api/second-resource должен быть доступен только пользователям с требованием "AnotherClaim" со значением 123.

Ресурсhttp://resourceserver.com/api/third-resource должен быть доступен для любых пользователей.

Когда я впервые услышал, что OAuth имел дело с ASP.NET WebAPI, я решил это следующим образом: когда запрос был отправлен сAuthorization: Bearer [token] заголовок, на стороне сервера был установлен принципал потока, и я подумал, что это означает, что пользователь прошел проверку подлинности с помощью API. Так что я использовал[Authorize] атрибуты, чтобы проверить, может ли пользователь получить доступ к ресурсу.

После более глубокого изучения OAuth я понял, что это ужасное злоупотребление протоколом. Как я узнал, OAuth авторизует приложения, а не пользователей. Как я узнал, когда выполняется запрос с заголовком Authorization, токен доступа не должен содержать информацию о пользователе, а только о том, что приложению разрешено делать запрос.

Учитывая это, отправка заголовка Authorization с запросом не идентифицирует пользователя и не говорит, может ли пользователь получить доступ к указанному ресурсу.

В таком случае, как выполнить такую ​​авторизацию? Я имею в виду не авторизацию клиентского приложения, выполняющего запрос, а авторизацию пользователя, обращающегося к ресурсу на основании его утверждений? Я верю, что именно здесь приходит OpenID Connect и его токены ID, но я не уверен. Как справиться с этим?