Почему и когда я должен использовать провайдер идентификации, такой как Auth0 или Azure AD B2 C, вместо того, чтобы просто хранить учетные данные пользователя в моей базе данных?

Question

Я разрабатываю ASP. NET Core API и пытаюсь сделать часть аутентификации и авторизации как можно лучше. Я изучаю OAuth 2 и OpenIDConnect (очень предварительные исследования на данный момент). Но с точки зрения разработчика API, что я могу получить, вставив в процесс Identity Provider, такой как Auth0 или Azure AD B2 C, вместо того, чтобы просто хранить учетные данные пользователя с использованием какой-либо криптографии?

Также Oauth 2, по-видимому, допускает множество потоков, связана ли работа API с потоком приложения, потребляющего этот API? Кажется немного неразумным. Я хочу просто иметь безопасный способ хранения учетных данных пользователя и позволить пользователям моего API выполнять аутентификацию и авторизацию, прежде чем использовать и манипулировать ресурсами других служб в API.

Я понимаю, что Аутентификация и авторизация - это важная тема c в приложении, поскольку они связаны с проблемами безопасности, и я планирую создать приложение, которое будет заниматься чувствительными финансовыми операциями. Это причина, по которой я вхожу после Auth0 и Azure AD B2 C. Но, честно говоря, у меня возникли небольшие проблемы с попыткой понять, что провайдеры идентификации, подобные этим, приведут к столу, я знаю, что они принесут что-то важное, мне просто нужна помощь, чтобы понять, что и почему я должен их использовать.

Answer 1

Чтобы добавить к @juunas:

• AI для проактивного мониторинга пользовательского доступа и отключения хитрых входов, например, при входе из США и России с интервалом в одну минуту
• Отчеты и статистика.
• Защита паролем, например, не позволяет пароль, который появился в нарушении
• Портал и API для пользователя CRUD
• MFA
• Самостоятельный сброс пароля
• Поддержка без пароля
• Поддержка Fido 2

Answer 2

что я могу получить, вставив в процесс провайдера идентификации, такого как Auth0 или Azure AD B2 C, вместо того, чтобы просто хранить учетные данные пользователя с использованием какой-либо криптографии?

Ну, вы получаете свободу не хранить учетные данные в вашей базе данных. Скорее всего, эти поставщики услуг заботятся о своей безопасности лучше, чем вы. Еще одна вещь, которую вы получаете, это Single Sign On. Многие приложения могут использовать одного и того же поставщика удостоверений для пользователей, поэтому пользователям необходимо всего лишь один раз войти в систему, чтобы использовать все приложения.

Конечно, это не нулевая стоимость, в OAuth / OID заложена сложность C. Но ни одно из них не строит ваше собственное хранилище пользователей.

Кроме того, Oauth 2, по-видимому, допускает множество потоков, разве работа API связана с потоком приложения, потребляющего этот API? Кажется немного неразумным.

Нет, API обычно не волнует, какой поток использует вызывающая сторона. Его беспокоит то, что он получает действительный токен доступа, который содержит необходимые разрешения для доступа к конкретному ресурсу. Клиентское приложение заботится о том, чтобы выбрать используемый поток.

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

Ну, вот что мне приходит в голову:

• Лучшая безопасность (скорее всего, речь идет не только об алгоритме хеширования паролей и т. Д. c.)
• Улучшенный SLA (создание службы SLA на 99,95%, такой как Auth0, не дешево)
• Проверенный послужной список
• Единая регистрация
• Единый идентификатор для пользователей всех ваших приложений, может легко отключить их учетную запись, а также запретить доступ ко всем приложениям одновременно
• Можно легко добавить поддержку федеративной аутентификации с другими поставщиками удостоверений
• Нет необходимости хранить хэши паролей и т. Д. c. в вашем приложении
• Готовые инструменты администрирования (которые нужно построить иначе)