Distrust: OpenID Connect 제공자로서의 Discourse

Discourse를 인증 제공자로 사용해보고 싶으셨다면, 이제 가능합니다!

지난 1주일 동안 Discourse를 백엔드로 사용하여 OpenID Connect/OAuth 제공자로 작동할 수 있는 작은 서비스를 개발했습니다.

코드는 아래에서 확인하실 수 있습니다:

주요 사용 사례가 Discourse를 통해 Nextcloud에 인증하는 것이었기 때문에, 사용자의 환경에서는 동작하지 않을 수 있습니다.

기대했던 대로 작동하지 않거나, 사용자의 환경에서 동작하려면 꼭 필요한 기능이 빠져 있다면 GitHub 저장소에서 이슈를 자유롭게 등록해 주세요.

19개의 좋아요

훌륭한 시도입니다! 저는 항상 Discourse가 OAuth 제공자로 사용되기를 원했는데, 이렇게 하면 다른 도구들과 쉽게 통합할 수 있습니다. 외부 소형 서비스로 만드는 것도 매우 합리적인 접근입니다!

6개의 좋아요

이 아이디어가 마음에 들고, 어떤 커뮤니티들이 직접 시도해 보기를 희망합니다!

우리는 자체적인 Discourse Connect 기능 외에도 OIDC가 Discourse에서 공식적으로 지원되기를 원합니다. 이를 통해 표준 및 팀 플랜의 고객들에게 okta와 같은 외부 솔루션에 의존하지 않고 바로 사용할 수 있는 턴키 솔루션을 제공할 수 있希기 때문입니다.

7개의 좋아요

정말 멋진 기능이에요! 이렇게 만들어 주셔서 감사합니다!

Discourse에 이 기능이 내장되어 자체 OIDC 제공자(OIDC provider)로 사용될 수 있으면 좋겠습니다!

5개의 좋아요

대단하네요, 그룹별로 접근할 수 있다는 점이 정말 좋습니다.

1개의 좋아요

@theSuess 저는 discourse를 단독으로 사용 중인데, 어떻게 설정해야 하나요?



Distrust는 별도의 서비스이므로 해당 방식으로 배포해야 합니다. README 파일에 설명된 대로 컨테이너에서 실행할 수 있습니다. 안전한 운영을 위해 SSL 종단(SSL Termination)을 처리하는 리버스 프록시도 필요합니다. (향후 이 기능을 직접 구현할 수도 있습니다.)

2개의 좋아요

Discourse를 SSO 제공자로 사용하면서 겪고 있는 문제에 대해 전문가의 조언을 구하고 있습니다.

목표: Discourse를 다른 애플리케이션(LibreChat)의 인증을 처리하도록 설정하고 있습니다. 표준 DiscourseConnect 제공자 기능을 사용하며, distrust OIDC 브리지 서비스가 Discourse와 통신하는 클라이언트 역할을 하고 있습니다.

문제: SSO 플로우가 마지막 단계까지 완벽하게 작동합니다. 사용자는 제 애플리케이션에서 Discourse로 올바르게 리다이렉트되며, Discourse 자격 증명으로 성공적으로 로그인할 수 있습니다. 그러나 로그인 후, 제공된 return_sso_url로 돌아가는 대신 제 Discourse 포럼의 홈 페이지(/)로 리다이렉트됩니다.

막힌 부분 (제거된 원인): 이 문제를 해결하기 위해 상당한 시간을 보냈으며, 이것이 단순한 설정 오류가 아님을 확인했습니다. 다음 사항들은 확실히 배제했습니다:

  • 비밀키(Secrets): discourse connect provider secrets가 올바르게 설정되어 있습니다. 프로토콜 없이 일반 도메인(예: auth.my-site.com)을 사용하며, 비밀 키는 제 클라이언트 서비스의 키와 정확히 일치합니다.
  • SSO 모드: enable discourse connect provider가 체크되어 있는지 확인했으며, 잘못된 “SSO Client” 설정은 비활성화되어 있습니다.
  • 사용자 정책: must_approve_users가 비활성화되어 있는지 확인했으며, 테스트 사용자는 완전히 검증된 이메일을 가진 관리자입니다.
  • 플러그인: 모든 비공식 제3자 플러그인을 비활성화하고 컨테이너를 재구축했지만, 문제는 여전히 지속됩니다.

핵심 증거: 저를 난감하게 만든 두 가지 결정적인 증거가 있습니다:

  1. HAR 파일 분석: HAR 파일로 전체 네트워크 플로우를 캡처했습니다. 로그인용 /session으로의 POST 요청이 성공적임을 보여줍니다. 서버는 즉시 302 Found 리다이렉트로 응답하지만, Location 헤더는 일관되게 /입니다. 이는 Discourse가 의도적으로 SSO 리다이렉트를 중단하고 있음을 증명합니다.
  2. 빈 Rails 로그: 로그인 시도를 하면서 컨테이너 내부의 production.log 파일을 테일링(tail)했습니다. 이 과정에서 로그에 아무것도 기록되지 않았습니다. 이는 Discourse가 이를 오류로 인식하지 않는다는 것을 의미하며, 의도적이고 조용한 동작임을 시사합니다.

질문: 로그에 오류가 없는데도 로그인은 성공적이지만 리다이렉트가 잘못되고, return_sso_url을 무시하고 홈 페이지로 리다이렉트하게 만드는 Discourse 내부 정책, 사전 검사(pre-flight check) 또는 숨겨진 설정이 무엇일까요? 표준 설정은 모두 다 확인해 본 것 같습니다.

사전에 아이디어를 주시면 감사하겠습니다!