В чем разница между разрешениями приложений и авторизацией oauth2?

Question

В настоящее время у нас уже есть приложение, это приложение, отделенное от внешнего и внутреннего, интерфейсное - это веб-приложение (SPA), внутреннее - это веб-API.

Дляприложение, у нас уже есть регистр использования, логин пользователя, роль пользователя, полномочия роли, проверка пользователя и проверка разрешения.

Сейчас мы интегрируем внешнюю службу идентификации (open id и Oatuh2), но я неправильно понимаю аутентификацию и авторизацию для внешней службы идентификации

Вопрос 1: ДаЯ могу использовать внешнюю службу идентификации для входа в систему и получения токена доступа, но после этого мне все еще нужно поддерживать пользователя в моем приложении, так как для бизнеса мне нужно знать, кто создает заказ, кто его использует и т. Д… итак,затем пользовательская система, что я делаю в своем приложении, мне все еще нужно делать, корректирует ли она то, что я делаю?

Вопрос 2: Для авторизации мне все еще нужно поддерживать роль пользователя,разрешение роли и проверка разрешения для себя в приложении, если да, то для чего нужна авторизация для службы идентификации (OAuth2)?А какая разница между модулем авторизации и разрешения OAuth2 в моем приложении?

Answer 1

Во-первых, OAuth 2.0 не определяет, как обрабатывать разрешения.Это определяет способ получения токенов доступа.Токены доступа - это секреты, которые ваш API принимает в качестве разрешений доступа (например: - сравните их с базовым заголовком аутентификации. Вместо этого теперь вы получаете токен).

Как выполнить проверку токена?У вас есть два основных варианта.Вы можете выполнить самоанализ токена ( RFC7662 ) против эмитента токена (службы идентификации).Ответ будет содержать полезную нагрузку, которая может содержать аутентифицированный конечный пользователь и данные об истечении срока действия токена.

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

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

Что касается аутентификации, она построена с использованием OpenID Connect и ID Token.Аутентификация будет происходить на стороне клиента (SPA, как в вашем случае).Это не зависит от вызова API.

Относительно разрешений, пользователей и отображений ролей.Если вы используете встроенное хранилище пользовательских данных, вам нужно будет сопоставить пользователя между внешней службой идентификации и внутренним хранилищем.В противном случае невозможно сопоставить пользовательские данные, которые вы получаете через токены (как описано в первой части ответа), со встроенными.Это нечто независимое от OAuth 2.0 и OpenID Connect.

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