Допущения (как я понял вопрос):
- Вы владеете и разрабатываете как внешний интерфейс (приложение Angular), так и внутренний (серверный REST API).
- Вы хотитепередать аутентификацию стороннему провайдеру идентификации.
- Вы хотите, чтобы приложение Angular (Клиент) содержало токен и могло проходить аутентификацию на бэкэнде (Ресурс-сервер) с удостоверением вашего пользователя (Владелец ресурса)), установленный на третьей стороне (Сервер авторизации / Identity Provider (IdP)).
Во-первых, боковой отвод.Для этого варианта использования лучше подойдет OpenId Connect (OIDC), поскольку он поддерживает элемент identity.Смысл OAuth2 заключается в том, чтобы авторизовать ваше приложение для работы с третьим лицом.Вам нужно установить личность вашего пользователя с помощью третьей стороны, и именно это делает OpenId Connect.
Хорошо, так что за поток (OIDC по-прежнему основан на OAuth2).
Первый вопрос: доверяют ли Клиенту что-либо на Ресурс-сервере и может ли он безопасно хранить секрет.Это явно не так, клиентское приложение не является доверенным и не может хранить секрет.В потоке учетных данных клиента клиент использует секрет для аутентификации на IdP для получения токена для сервера ресурсов.Это будет означать, что ваше приложение Angular хранит пароль, который оно использует для получения токена для вашего бэкэнда, явно не то, что вам нужно.
Поток учетных данных пароля владельца ресурса используется, когда клиент доверяет обработке учетных данных пользователя.В вашем случае это не очень хорошо, потому что практически это будет означать, что ваше приложение Angular получит пароль пользователя для пересылки его в IdP в обмен на токен.У вашего Клиента не должно быть доступа к паролю пользователя, ему не доверяют.
Теперь перейдем к более интересной части.
Вопрос в том, есть ли у вашего Клиента серверная сторона для безопасного хранениясекрет.Если это так, то предоставление кода авторизации хорошо, потому что оно позволяет вашему пользователю проходить аутентификацию на IdP, перенаправляться обратно с кодом авторизации, а затем на стороне сервера может обменивать его на токен доступа, который будет использоваться на сервере ресурсов.Однако ваш Клиент в этом сценарии не имеет серверной части, насколько я понимаю, API является сервером ресурсов.Так что это нехорошо для вас, потому что ему нужен секрет клиента, и вы не можете сохранить его в своем приложении Angular.
И это в значительной степени оставляет вас с неявным потоком, для которого вы не делаетенужен секрет клиента, но с другой стороны сложно сделать такие вещи, как обновить токены.В потоковой диаграмме, с которой вы связаны, последний вопрос заключается в том, является ли ваш клиент SPA - и в вашем случае это так, поэтому вам следует обратиться к неявному потоку по умолчанию.
Это, вероятно, самая безопасная модель дляВы, потому что даже в случае компрометации вашего Клиента ваши учетные данные пользователя остаются в безопасности (приложение Angular никогда не имеет доступа).
Однако вы можете смоделировать все это по-другому, и это значительно упрощаетбит.
Насколько я понимаю, у вас есть клиент и сервер ресурсов, а владелец ресурса использует клиент, вы просто хотите разгрузить аутентификацию, пока вы все еще управляете пользователями в сторонней службе.
С этой точки зрения вашему Клиенту доверяют доступ к учетным данным пользователя, а пользователь, использующий его, является владельцем ресурса.Таким образом, вы можете использовать поток паролей владельца ресурса, где пользователь вводит свои учетные данные непосредственно в приложение Angular, которое отправляется в IdP, получает токен, а Angular просто использует его для доступа к содержимому API (Resource Server).
Риск по сравнению с неявным потоком состоит в том, что если приложение Angular скомпрометировано, учетные данные пользователя будут раскрыты злоумышленнику.Хотите ли вы принять этот риск, полностью зависит от вас.Обратите внимание, что это, очевидно, не сработает, если IdP - это хорошо известная служба (например, социальный веб-сайт), потому что, как ваш пользователь, я бы не хотел предоставлять пароль своего социального сайта вашему приложению.Но пока вы все равно управляете пользователями, можно доверять Клиенту.