Блог

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

Для приложения у нас уже есть use register, логин пользователя, роль пользователя, разрешения роли, проверка пользователя и permission check.

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

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

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

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

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

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

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

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

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

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