OIDC OAuth 2.0 Аутентификация и авторизация - PullRequest
0 голосов
/ 24 октября 2019

Мы зарегистрировали наше приложение в OIDC, используя тип аутентификации 2L. Нужно ли нам предоставлять наш клиентский идентификатор и секретный ключ для доступа к нашему API? ,

И поскольку многие пользователи будут получать доступ к нашему API, вместо того, чтобы делиться учетными данными наших клиентов, мы можем разрешить доступ к нашему API. Существует ли ACL в OIDC, где мы можем предоставить доступ потребителю A, а не Потребителю B, при условии, что и A, и B зарегистрировали свои приложения в OIDC.

1 Ответ

0 голосов
/ 05 ноября 2019

Спецификация Oauth 2.0 определила концепцию scope , которая используется для выражения авторизации токена доступа.

Таким образом, в Oauth 2.0 "ACL", который вы упомянули выше, выражаетсяпо объему. Когда вы регистрируете одного клиента в IdP, вы должны указать область действия этого клиента, эта область будет «где мы можем предоставить доступ потребителю A, а не потребителю B».

Будет разработан ваш API (сервер ресурсов)так что конечная точка примет запрос имеет токен доступа с соответствующей областью действия.

Например:

Зарегистрировать клиентов: client A (scope = email), client B (scope = address)

Получить токен доступа для каждого клиента (по потоку client_credential): access_token_A, access_token_B

Ваш API: конечная точка1 - (авторизовано email scope). Таким образом, когда вы отправили два запроса, один с access_token_A и один с access_token_B , предыдущий запрос будет успешным (правильная область действия), а позже будет неудачным.

Ссылки:

[https://www.oauth.com/oauth2-servers/the-resource-server/][1]

https://tools.ietf.org/html/rfc6749

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...