Таблица Applications
содержит клиентские приложения OAuth2, которым разрешено использовать ваш сервер идентификации.
Добавление новой записи обязательно при использовании интерактивных потоков, таких как код авторизации или implicit, поскольку клиентские приложения должны отправлять действительный client_id
: OpenIddict отклонит запрос авторизации, если client_id
отсутствует или не соответствует приложению, которому вы полностью доверяете (т. е. приложению, хранящемуся в таблице Applications
).
То же правило применяется к предоставлению учетных данных клиента, для которого также требуется действительный client_id
.
Напротив, есть один случай, когда отправка client_id
не является обязательной: при использовании учетных данных пароля владельца ресурса grant, как показано в упомянутом вами сообщении в блоге.
В спецификации прямо указано, что клиентское приложение, выполняющее запрос токена, МОЖЕТ отправлять свои client_id
, что означает, что этот параметр не является обязательным.
Клиент МОЖЕТ использовать параметр запроса client_id для идентификации себя при отправке запросов к конечной точке токена.
Когда из запроса токена не может быть извлечено client_id
, OpenIddict не может определить идентичность приложения. В этом случае проверки, связанные с client_id
, пропускаются, и запрос обрабатывается без использования таблицы Applications
. Вот почему ваше приложение работает без необходимости заполнять Applications
таблицу.
Хотя отправка client_id
полезна для ведения журнала, отправка client_id
не делает grant_type=password
запросы более безопасными, поскольку каждый может выдавать себя за приложение, повторно используя тот же client_id
, если только приложение не было объявлено конфиденциальным и ему были назначены учетные данные клиента (см. "Серверные приложения" Только"). В этом случае злоумышленник не может отправить действительный запрос токена, не зная client_secret
.
В OpenIddict также есть один случай, когда добавление явной регистрации приложения полезно: при использовании промежуточное программное обеспечение интроспекции для проверки токенов доступа (вместо промежуточного программного обеспечения носителя JWT).
Как требуется спецификацией, вызывающие абоненты должны пройти аутентификацию, чтобы использовать конечную точку самоанализа: если OpenIddict не может найти соответствующую запись в таблице Applications
, запрос будет отклонен, и промежуточное ПО для самоанализа никогда не будет работать.
person
Kévin Chalet
schedule
23.05.2016