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

Question

ASP.NET Core имеет встроенную поддержку Google, Facebook and Twitter аутентификация. Эта статья MSDN освещает это довольно хорошо.

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

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

Answer 1

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

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

Причина на самом деле проста: реализовать ее чрезвычайно рискованно, так как она подвержена недооцененному классу атак: запутанная атака депутатов. Подробности о том, как работает эта атака, можно найти в этом замечательном ответе SO (примечание: в нем упоминается неявный поток, но он фактически работает с любым потоком, когда запутанным заместителем является сам API):

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

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