По-видимому, вы описываете здесь OpenID Connect “Implicit Flow”, который работает без какого-либо сервер-серверного взаимодействия и поэтому не требует общего секрета. Вместо этого вся информация передаётся через HTTP-перенаправления, а ID-токен криптографически проверяется с использованием открытых ключей из Discovery-документа.
Это допустимо, и я считаю, что это валидная просьба о новой функции. Однако это совершенно другая система по сравнению с нашим текущим плагином, который использует authorization code flow. Этот поток использует сервер-серверное взаимодействие с общим секретом, поэтому криптографическая проверка id_token не требуется. В некоторых аспектах это проще, но в других — сложнее.
Важно: мы не можем просто изменить реализацию по умолчанию в плагине. Сайты, использующие authorization-code flow, должны продолжать использовать его. Насколько я помню, многие провайдеры идентификации вообще не поддерживают Implicit Flow.
Поэтому я вижу два возможных пути развития:
-
Мы добавляем поддержку “implicit flow” в плагин OIDC, но делаем это опциональным. Я считаю маловероятным, что мы примем PR, который добавляет gem openid-connect как зависимость ядра Discourse, поэтому реализация должна быть выполнена в рамках нашей текущей стратегии.
Плагин discourse-lti (интеграция инструментов обучения) может послужить полезным источником вдохновения, поскольку протокол LTI основан на implicit flow OIDC. Логика декодирования id_token находится здесь.
Или, альтернативно,
- Вы создаёте implicit flow как совершенно новый плагин. В этом случае вы будете свободны в выборе реализации (но вам также придётся поддерживать его самостоятельно).