Идентификатор сеанса для OpenID Connect

Question

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

Я думаю id_token более чем достаточно, как идентификатор сеанса, но от моего понимания, предпочтительно, чтобы не подвергать id_token вне сервера, если это возможно для более тесной безопасности. Как мне выбрать session_id, что является идеальным способом управления сессиями для этого случая? Я использую WSO2 Identity Server

Answer 1

Управление сеансом, это признак, наиболее часто связанный с веб-приложениями, поэтому я предполагаю, что это то, что есть в приложениях 1 и 2. . Вы можете найти эту статью (Single Sign-On for Regular Web Apps интересно читать, в частности, раздел о session management

Когда речь идет об управлении сессий, там, как правило, три слоя сессий мы должны рассмотреть:

• Application Session
• Auth0 (Федерация Provider) сессия
• Идентичность Provider сессия

Это было бы применимо к вам, если вы планировали иметь свой сервер аутентификации дополнительно делегировать проверку подлинности дополнительного провайдера идентификации, как Google или Facebook.

---

Лично я бы не использовать идентификационный маркер в качестве идентификатора сеанса и вместо того, чтобы использовать более короткий ID и сохранить состояния сеанса на стороне сервера.

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

Предыдущее означает, что наличие токенов ID пересекает границу на стороне сервера полностью в порядке и что ваши намерения использовать его в качестве значения cookie сеанса в порядке.

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