저희는 Topicbox 를 자체 호스팅되는 Discourse로 이전할 예정입니다. 현재 사용하는 Topicbox는 매우 개방적입니다(대부분의 구독자는 승인되며, 초기 게시물은 검토됩니다). 하지만 새로운 Discourse에서도 스팸, 해커 등의 문제가 발생하지 않기를 원합니다. Discourse에서는 Google, GitHub 및 몇 가지 신뢰할 수 있는 소스를 통한 인증을 허용할 계획입니다.
과거 몇 년간 이 주제에 대해 Discourse ID를 통한 인증 활성화의 위험에 관해 상반된 의견들을 확인했습니다. 따라서 Discourse ID를 사용한 로그인 허용에 대한 현재의 통념은 무엇인지 궁금합니다. 이 방식의 이점이 잠재적인 단점/위험을 상회하는지, 아니면 구글 검색 결과에서 제시하듯 그 정도로 나쁜 것인가요? Discourse ID의 위험이 광범위한 GitHub 및 Google 소스를 통한 로그인 허용보다 더 심각한가요?
단계별로 진행하면 안 될까요?
먼저 명백한 우선순위가 높은 소셜 로그인을 시작하고, 나중에 Discourse ID를 추가하는 방식이요?
거기에 나열된 위험들은 대부분 사람들이 말하는 "환각(allucinations)"에 해당합니다.
평판 불일치: 다른 포럼에서 얻은 신뢰 수준(TL0–TL4)이 커뮤니티의 기준과 일치하지 않을 수 있으며, 이로 인해 외부 사용자가 지역에서 획득하지 못한 게시 또는 모더레이션 권한을 부여받을 수 있습니다.
Discourse ID는 그렇게 작동하지 않습니다.
데이터 의존성: 신원 확인을 위해 외부 서버나 네트워크에 의존하게 됩니다. 원격 로그인 제공자가 다운타임이나 API 규칙 변경을 겪는 경우, 사용자의 접근이 차단될 수 있습니다.
모든 소셜 로그인이 동일한 상황입니다.
연쇄적 취약성: 사이트의 보안 포스처가 가장 약한 참여 사이트나 중앙 신원 제공자에 종속됩니다. 외부 파트너 사이트가 해킹되면, 악의적 행위자들이 해당 계정을 악용하여 인스턴스에 접근할 수 있습니다.
Discourse ID는 Discourse 위에 구축되어 있으며, 이는 커뮤니티가 실행하는 것과 동일한 소프트웨어입니다.
계정 탈취 전파: 사용자가 약한 비밀번호를 사용하거나 원격 참여 사이트에서 자격 증명 유출 사고를 겪는 경우, 그 손상된 상태가 포럼 인증 플로우로 직접 전파될 수 있습니다.
이것은 말이 되지 않습니다.
노력 없이 다양한 소셜 로그인을 얻고 싶다면 Discourse ID를 사용하세요. 사용자가 사이트에 로그인할 때 사용할 수 있는 방법을 정확히 제어하고 싶다면 사용하지 마세요.
어떻게 표현하느냐에 따라 달라지는 거지 
피드백을 주신 모든 분들께 감사드립니다. 제 추론을 뒷받침해 주네요. (요즘 구글 검색 결과를 누가 믿겠습니까?)
질문: 제 첫 번째 질문의 반대편을 생각해 보면, 선택적으로 로컬 계정을 허용하는 방법이 있을까요? 예를 들어, 관리자용 계정은 우리 디스코스에서 생성하도록 허용하되, 나머지는 모두 GitHub 등을 통해 생성하도록 요구하는 식으로요. 이는 잠재적 관리자에게 초대장을 보내는 방식으로 실현 가능한가요? 즉, 로컬 계정을 생성할 수 있는 유일한 방법이 초대장인 경우 말입니다.
관리자 계정에 대한 보안을 강화하려면 Enforce second factor(이중 인증 강제)를 staff(스태프)로 전환할 수 있습니다.
