Социальная аутентификация в Web Api Core

Question

ASP.NET Core имеет встроенную поддержку для проверки подлинности Google, Facebook and Twitter. Это msdn article покрывает его довольно хорошо.

Но похоже, что он работает только для MVC, но для Web Api вам нужно реализовать много вещей по своему усмотрению. Благодаря Openiddict Мне удалось сделать это для моего проекта, но по-прежнему кажется, что я должен написать довольно низкоуровневый код, который должен быть частью фреймворка.

Было бы неплохо иметь простые звонки, такие как app.UseGoogleAuthentication в Web Api. Поэтому мой вопрос в том, почему они не поддерживаются на данный момент (есть ли какие-либо архитектурные проблемы), и есть ли планы поддержать его в конце концов?

Answer 1

Итак, мой вопрос в том, почему они не поддерживаются на данный момент (есть ли какие-либо архитектурные проблемы), и есть ли планы поддержать его в конце концов?

Пока я не могу говорить за ASP.NET команды о том, почему они не хотят работать над проектом провайдера идентичности (я догадываюсь было бы напрямую конфликтует с коммерческими предложениями Microsoft, Azure AD и Azure B2C), я могу сказать вам, почему напрямую Принимая сторонние токены, которые не были предназначены для использования вашим приложением, не является хорошей идеей и, следовательно, почему она никогда не поддерживалась в OWIN/Katana и ASP.NET Core ,

Причина на самом деле прост: это крайне рискованно осуществлять, так как это склонно к заниженному классу атаки: запутанный заместитель атаки. Подробнее о том, как эта атака работает can be found in this great SO answer (примечание: он упоминает о неявном потоке, но он на самом деле работает с любым потоком, когда запутаться заместитель является сам API):

1. Алиса подписывает в FILESTORE с помощью Google.
2. После процесса аутентификации FileStore создает учетную запись для Алисы и связывает ее с идентификатором пользователя Google XYZ.
3. Алиса загружает файлы в свою учетную запись FileStore. Пока все в порядке.
4. Позже Алиса подписывается на EvilApp, в которой предлагаются игры, которые выглядят как бы весело.
5. В результате EvilApp получает токен доступа, связанный с идентификатором пользователя XYZ Google.
6. Теперь владелец EvilApp может создать URI перенаправления для FileStore, вставив токен доступа, который был выпущен для учетной записи Google Алисы.
7. Злоумышленник подключается к FileStore, который принимает токен доступа и проверяет с помощью Google, для какого пользователя он предназначен. Google скажет, что это пользователь XYZ.
8. FileStore предоставит злоумышленнику доступ к файлам Алисы, поскольку у злоумышленника есть токен доступа для пользователя Google XYZ.

Ошибка FileStore не подтвердила с Google, что токен доступа, который был предоставлен, был действительно выпущен FileStore; маркер действительно был выпущен EvilApp.