Создание веб-API с подключением Oauth2/OpenID

Я пытаюсь понять концептуально и практически, как выполнить oauth2 с потоком openID-connect в моем приложении web-api, используя Azure AD.

Важно отметить, что когда запрос поступает в API, я хочу знать, кто сделал запрос.

Мое настоящее понимание: -

  • Мой клиент обнаружит, что пользователь не зарегистрирован и не перенаправлен на вход.
  • Пользователь предоставит свои учетные данные и будет перенаправлен обратно клиенту вместе с токеном oauth2.
  • Этот токен будет передаваться в конечные точки web-api для любых запросов.

Вот где это становится мутным для меня.

Как именно я использую этот токен, чтобы разрешить доступ к определенному ресурсу, определить, кто обращается к ресурсу, и каков механизм, который это делает?

Я вроде бы предполагаю, что мне нужно будет повторно использовать токен для вызова конечной точки пользователя Azure AD - если токен действительно действительно, конечная точка AD вернет детали пользователей, тем самым предоставив некоторые средства для определения что токен действителен и предоставляет подробную информацию о личности пользователей. Разрешение доступа к ресурсу может быть выполнено через членство в группах в Azure AD.

НО...

Я могу только предположить, что это решена проблема, и заметили использование промежуточного ПО OWIN в соответствии с этим примером

https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet

Но я все еще не уверен, что происходит.

В службе упоминаются области и заявки, но я не понимаю, откуда они получены (я полагаю, из токена, предоставленного клиентом, но не уверен). Служба должна получать идентификационную информацию в вызове.

Это приводит меня к двум точкам, поскольку это безопасно -

  • Токен, предоставляемый при вызове услуги, должен быть защищен при передаче (следовательно, использование HTTPS) - для предотвращения MITM.

  • Необходимо отметить, что токен должен быть подписан каким-то образом - я полагаю, используя секрет клиента или что-то еще - для предотвращения подделки информации в токене.

Может кто-нибудь помочь мне разобраться в этом запутанном беспорядке?

В частности -

  • Как определяется идентификатор вызывающего API-адреса - определяется ли идентификатор из вызова на клиенте или сервере?

  • Как ограничить доступ к некоторым конечным точкам API на основе роли пользователя?

  • Что мне делать, чтобы достичь этого, основываясь на существующем промежуточном программном обеспечении и библиотеках, доступных мне?

2 ответа

Отказ от ответственности: это не будет исчерпывающий ответ. Это не в моей голове.

OpenID Connect обеспечивает уровень идентификации поверх OAuth. В вашем случае Active Directory предоставляет аутентификацию и отправляет обратно access_token. Маркер доступа представляет пользователя, прошедшего проверку подлинности AD. Если вы выполняете OpenID Connect, тогда AD также отправит id_token, который может содержать дополнительную идентификационную информацию (например, день рождения, аватар и все, что выдает AD).

Ни OpenID Connect, ни Active Directory не имеют ничего общего с ролями, которые ваше приложение назначает пользователю; роли - это все, что вам нужно. Вы назначаете роли пользователя точно так же, как обычно; вы назначаете их nameid, но вместо адреса электронной почты или имени пользователя. Вашему приложению больше не нужно аутентифицировать пользователя, но ему нужно назначить роли nameid.

Как определяется идентификатор вызывающего API-адреса - определяется ли идентификатор из вызова на клиенте или на сервере?

Тождество внедрено в access_token, которое AD включает в свой ответ. Этот токен будет иметь nameid, в котором ваше приложение может ассоциироваться с пользователем и ролью. nameid похож на адрес электронной почты, имя пользователя или другой уникальный идентификатор, который ваше приложение использует для распознавания пользователя.

Как ограничить доступ к некоторым конечным точкам API на основе роли пользователя?

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

Что я могу сделать для достижения этого, основываясь на существующем промежуточном программном обеспечении и библиотеках, доступных мне?

Здесь есть незавершенная демонстрация, хотя он не использует Active Directory в качестве поставщика, вместо этого он использует внутренний провайдер. Для демонстрации имя пользователя *****, а пароль - Testing123!. Исходный код здесь.

Здесь ссылка на источник другой демонстрации, но опять же, она не использует Active Directory в качестве поставщика, а вместо этого использует Twitter.

Самое приятное в OAuth и OpenID Connect заключается в том, что мы можем использовать любой поставщик идентификационных данных, который мы хотим, поэтому вы можете адаптировать демоверсии для использования Active Directory.


Помимо вопроса № 1 (идентификация проверяется на стороне обслуживания), все ваши вопросы очень открыты и потребуют супер длинного ответа. Я бы рекомендовал читать https://azure.microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ - это хорошее введение в потоки, лежащие в основе многих современных сценариев аутентификации, включая веб-API, который вы используете сфокусироваться на. Как только вы прочтете это, вы найдете полный набор образцов в https://azure.microsoft.com/en-us/documentation/articles/active-directory-code-samples/ - в частности, я предлагаю изучить веб-API и через авторизацию один, чтобы найти руководство по 3 указанным вами вопросам. НТН!

licensed under cc by-sa 3.0 with attribution.