여기서 말씀하시는 내용은 서버 간 통신 없이 작동하는 OpenID Connect의 "Implicit Flow"인 것 같습니다. 따라서 공유 시크릿(shared secret)이 필요하지 않습니다. 대신 모든 정보가 HTTP 리다이렉트를 통해 전송되며, ID 토큰은 Discovery Document의 공개 키를 사용하여 암호학적으로 검증됩니다.
이것은 괜찮은 방법이며, 유효한 기능 요청이라고 생각합니다. 하지만 이것은 현재 우리가 사용하는 플러그인과 매우 다른 시스템입니다. 현재 플러그인은 인가 코드 플로우(authorization code flow)를 사용하며, 이 플로우는 공유 시크릿을 통한 서버 간 통신을 사용하므로 id_token의 암호학적 검증이 필요하지 않습니다. 어떤 면에서는 더 단순하지만, 다른 면에서는 더 복잡합니다.
중요한 점은: 플러그인의 기본 구현을 단순히 변경할 수 없다는 것입니다. 인가 코드 플로우를 사용하고 있는 사이트들은 계속 그 방식을 사용해야 합니다. 기억이 맞다면 많은 인증 제공자(IDP)가 Implicit Flow를 지원하지조차 않습니다.
따라서 앞으로의 방향은 두 가지가 있다고 생각합니다:
-
OIDC 플러그인에 “implicit flow” 지원을 추가하되, **선택적(opt-in)**으로 만듭니다. openid-connect gem을 Discourse 코어에 의존성으로 추가하는 PR을 승인할 가능성은 낮으므로, 현재 전략 내에서 구현되어야 합니다.
discourse-lti(학습 도구 통합) 플러그인이 유용한 참고 자료가 될 수 있습니다. LTI 프로토콜은 OIDC implicit flow에 기반하기 때문입니다. id_token 디코딩 로직은 여기에 있습니다.
또는
- implicit flow를 완전히 새로운 플러그인으로 구축합니다. 이 경우 구현 방식에 대해 자유롭게 결정할 수 있지만(단, 직접 유지보수도 해야 합니다).