Discourse as SSO provider for multiple clients

아니요, 그냥 제 머릿속에 떠오른 가장 복잡한 회로일 뿐입니다. 그리고 저는 그저 디스커스의 한계를 시험해 보고 있을 뿐입니다. 현실에서는 아직 이렇게 어려운 작업을 많이 다루어 본 적이 없으며, 이제 SSO 작업만을 위해 별도의 디스커스를 할당하는 것은 과잉 설계(overengineering)라고 생각합니다. 만약 이 단계까지 도달했다면, 잘못된 방향으로 가고 있는 것입니다.

지금 저는 일반에서 특수로 나아가야 한다는 아이디어를 따르고 있습니다. 즉, 위에서 제시한 예시를 계속하자면, 먼저 모든 반려동물, 그 치료법과 먹이에 전념하는 일반 포럼을 열어야 합니다. 그리고 포럼이 성장하면서 몇몇 큰 카테고리를 별도의 포럼으로 분리할 필요를 느끼게 될 것입니다(예를 들어, 고양이 주인과 개 주인은 가장 큰 카테고리이며, 서로 잘 지내지 않고 일반적으로 서로의 문제에 대해 큰 관심을 보이지 않으므로). 그때야말로 원래의 포럼을 두 개의 새 포럼을 위한 SSO 제공자로 사용할 수 있습니다. 이렇게 하면 모든 포럼이 시너지를 내면서도 지나치게 가까운 인접성으로 인한 문제를 겪지 않을 것입니다.

제가 두 번째로 보는 사용 사례는 별도의 언어별 포럼을 생성하는 경우입니다. 이때 중앙 포럼이 주요 언어로 운영되고, SSO를 통해 주제와 연결된 다른 언어의 여러 포럼이 설치되는 형태입니다. 하지만 이는 사용되는 모든 언어에 대한 지원이 동등할 때만 수행해야 합니다. 그리고 아마도 처음에는 언어별 별도 카테고리가 있는 하나의 포럼으로 시작하는 것이 좋으며, 포럼이 성장하여 소통이 불편해졌을 때 비로소 서로 다른 포럼으로 나누는 것이 좋습니다.

여기서 핵심은 모든 포럼 간의 사용자 계정 자동 동기화 및 하나에 로그인했을 때 모든 포럼/사이트에 자동 로그인되는 기능이어야 합니다.