Можно ли повторно использовать токен доступа на нескольких серверах - IdentityServer4

Question

В настоящее время мы создаем веб-приложение, у нас есть веб-сервер и сервер приложений, на котором размещены наши ресурсы. Также мы будем использовать Mule ESB, чтобы иметь возможность использовать любой веб-сервис или API. И у нас будет решение Alfresco DMS, и мы будем использовать сервис Alfresco с Mule ESB.

Мы изучаем, как мы можем реализовать подход SSO для этого сценария. У нас уже есть IdentityServer4 для федерации идентификации. Он выдает токен доступа для клиента, и мы должны аутентифицировать пользователя всякий раз, когда пользователь на стороне Mule ESB не запрашивает у пользователя учетные данные снова. Согласно моим исследованиям, внешний Identiy предоставить можно добавить на Mule ESB. Мы не делаем того, чтобы токен доступа выдавал клиенту при входе пользователя на сервер приложений в Mule ESB, а Mule ESB мог проверять токен доступа до

На самом деле вопрос, на который мы ищем ответ, заключается в том, можно ли выдать клиенту токен доступа только один раз, а затем проверить этот токен на каждой стороне (Mule ESB, Alfresco), не прося пользователя вводить учетные данные снова и снова .

Answer 1

Использование токена доступа для нескольких приложений не рекомендуется. Это выделяется через это и это ресурсы. В основном область действия токена доступа должна быть ограничена. Это должно предотвратить злоупотребление токеном доступа.

В вашем сценарии у вас есть несколько приложений. Если ваша цель - использовать один токен доступа, общий для всех, я советую этого не делать. Вместо этого вы можете использовать один токен доступа для нескольких API, если вы запрашиваете токены доступа с такой областью действия. Например, API в ESB могут быть спроектированы так, чтобы принимать маркеры доступа, если это позволяет область действия (область может быть проверена от конечной точки API до самоанализа токена ). Но разрешите каждому клиентскому приложению получать свои токены. Это сделает вашу архитектуру более безопасной.

Одним из решений для единого входа является использование единого входа на основе браузера. Поставщики удостоверений поддерживают сеанс в браузере. Так что, если один из ваших клиентов пройдет регистрацию, ваш следующий клиент будет использовать этот предыдущий сеанс, чтобы пропустить страницу входа. По сути, это SSO-поведение. Например, это то, что позволяет вам использовать Gmail, Youtube и Google Drive с одним логином. Браузер поддерживает сессию с Google. Каждое приложение получает токены, но пропускает страницу входа.