Use Discourse as an identity provider (SSO, DiscourseConnect)

cookieman768 · 2022 年 1 月 26 日午前 5:09

Minecraftサーバーのアカウント連携システムを作成するためにこれを使用できました！どのようなものになったか共有したいと思います！Discourse SSOを扱うのは初めてだったので、すべてを複雑にしすぎたかもしれませんが、機能することが最も重要です。

Devarsh_Mavani · 2022 年 6 月 12 日午前 10:23

すべて正しく行いましたが、ユーザーがDiscourseにログインしていない場合、ユーザーログインポップアップが表示されます。ユーザー名とパスワードを入力しても、return_urlにリダイレクトされません。手伝っていただけますか？

mksafi · 2022 年 7 月 28 日午後 11:01

nonce はリプレイ攻撃を防ぐためのものだと想定しています。オンラインで、HTTPS を使用している場合はリプレイ攻撃は不可能だと読みました。そのため、それでも nonce は必要ですか？どこに保存すればよいかわからないので質問しています。ユーザーのブラウザにセキュアなプレーンテキストの Cookie として保存し、それを返されるペイロードと一緒にブラウザから読み取るのは理にかなっていますか？

元の投稿 GitHub - ArmedGuy/discourse_sso_node: npm package for Discourse SSO login features. からリンクされているこのライブラリは、ユーザーを検証する際に nonce を使用していません。

Osama · 2022 年 7 月 29 日午前 2:40

はい、nonceを検証する必要があります。これは、Discourseがユーザーをサイトにリダイレクトする際に送信するペイロードの再利用を防ぐためです。

たとえば、あなたのサイトにはDiscourseのsubscribersグループのメンバーのみがアクセスできるペイウォール付きのコンテンツがあり、Discourseがあなたのサイトに送信するペイロードのgroupsフィールドを使用して、サブスクライバーのみに有料コンテンツを表示するとします。nonceを検証しない場合、もはやsubscribersグループに属していないユーザーが、メンバーだった頃の古いペイロードを使用してサイトにログインし、有料コンテンツを表示できてしまう可能性があります。

nonceは短い有効期限とともにデータベースに保存し、使用され次第データベースから削除するのが最善です。しかし、データベースを使用できない場合は、Cookieを使用してnonceを保存できますが、ペイロードの再利用を防ぐために追加の手順を実行する必要があります。

nonceを生成する際に、たとえば現在時刻から10分後などの有効期限を付けます。
Cookie全体（nonce + 有効期限）に署名して、ユーザーがnonceや有効期限を変更できないようにします。
Cookieの署名を検証し、nonceが期限切れでないことを確認します。

これにより、ペイロードの再利用に対して十分な保護が得られます。技術的にはペイロードの再利用は依然として可能ですが、それは永遠ではなく10分間のウィンドウに限定されます。

Cookieを必要としないより簡単な解決策は、生成するペイロードにカスタムフィールドとして有効期限を含めることです。次に、Discourseがユーザーをペイロードとともにサイトにリダイレクトすると、カスタムフィールドが含まれ、有効期限を取得して期限切れでないことを確認できます。ペイロードにカスタムフィールドを含めるには、custom.で始まるフィールドを含める必要があります。したがって、ペイロードは次のようになります。

nonce=NONCE&return_sso_url=RETURN_URL&custom.expiration_date=TIMESTAMP

RGJ · 2022 年 7 月 29 日午前 6:21

セッションにノンスを保存することもできます。これにより、ユーザーがノンスを改ざんするのを防ぐこともできます。

EGreg · 2022 年 8 月 21 日午後 9:13

数年後にこのスレッドに戻ってきました

Discourse SSOプロバイダーが何を返すか、誰か教えていただけますか（@pfaffman、@tobiaseigen、@iamntzのいずれか）？「試してみればわかる」ことは承知していますが、文書化されていると便利です。GitHubのPHPサンプルコードには、他のフィールドはほとんど言及されていません。

理想的には、DiscourseがSSOに外部スクリプトを使用する場合と同じフィールド、つまり外部ID、メールアドレス、ユーザー名、名前、アバター写真などを送信してくれると良いのですが。そうすれば、これをインポートして、こちら側でユーザーを作成できます！

WordPressにもメールアドレスを伝えますか？

グループやバッジなどはどうでしょうか？REST呼び出しでこれらの情報を取得できますか？

最後に、ユーザーのプライベートメッセージやその他のものについてはどうでしょうか？DiscordがOAuthプロバイダーであり、私たちのアプリがこれらのものを消費できるようにしてくれれば、素晴らしいと思います。

Roie_Natan · 2022 年 12 月 15 日午前 2:15

Discourse Connect を有効にしようとすると、次のエラーが発生します。
enable_discourse_connect: You cannot enable DiscourseConnect and invite only at the same time.

何か考えはありますか？

simon · 2022 年 12 月 15 日午前 4:49

こちらでも同じ質問をされているようですが、Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - #537 。もしenable discourse connect設定を構成しようとしていて、enable discourse connect provider設定ではない場合、他のトピックで質問するのが適切です。

enable discourse connect provider設定は、Discourseサイトを別のサイトのIDプロバイダーとして使用したい場合に使用します。enable discourse connect設定は、外部サイト経由でDiscourseにユーザーをログインさせたい場合に使用します。

piffy · 2022 年 12 月 18 日午前 6:09

私が構築中のFlaskアプリケーションにPythonで手順を実装しました。必要であれば、誰でも使えるように、ここにいくつかの定型コードを記載します。このトピックで説明されている手順は非常に簡単に実行できましたが、私はセキュリティの専門家ではないため、何か見落としがあれば教えてください！

gist.github.com

https://gist.github.com/ScottMastro/011b7a823177aeac67ae9022aac35cee

discourse_sso.py

# Copyright 2022
# Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
# The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

import secrets
import base64
import hashlib
import hmac
from urllib import parse

This file has been truncated. show original

sfoster · 2023 年 5 月 10 日午後 11:21

Discourse を SSO プロバイダーとして実装しようとしていますが、Discourse がどのユーザーを確認する必要があるのかがわかりません。指示には「nonce と return url を含む新しいペイロードを作成する」とありますが、これを Discourse に fetch で POST するとき、Discourse はどのユーザーを確認してログインしているかどうかを判断するのでしょうか？愚かな質問かもしれませんが、この仕組みがどうしても理解できません。長年多くの認証システムを扱ってきたので、ある程度は理解しているつもりです。確認したいユーザーのメールアドレスを Discourse に送信するペイロードに含める必要があるのでしょうか？もしそうなら、Discourse に送信する必要があるペイロードの正確な構造はどうなりますか？もしそうでないなら、Discourse は具体的に何をチェックしているのでしょうか？こちら側でユーザーにメールアドレスを尋ね、そのメールアドレスを含むペイロードを Discourse に送信して、その特定のユーザーがログインしているかどうかを確認するというのが私の推測ですが、指示にはそう書かれていないため、完全に混乱しています。何か助けがあれば幸いです。

sfoster · 2023 年 5 月 11 日午前 12:10

問題ありません。解決しました。SSO URLをDiscourseインスタンスにPOSTリクエストとして送信し、応答を受け取る必要があると考えていました。しかし、これはDiscourseへのリダイレクトであり、その後Discourseが私たちのサイトにリダイレクトし直すことがわかりました。したがって、何をすべきかは明確になりました。以前の投稿は申し訳ありませんでした。

mdoggydog · 2023 年 9 月 28 日午前 5:19

FYI/FWIW: 認証リクエストで prompt=none パラメータを許可するPRを提出しました。OpenID Connectプロトコルと同様の機能で、これによりSSOコンシューマーは、ユーザー/クライアントがログインしていない場合にログインダイアログに送信することなく、すでにログインしているかどうかを確認できます。

PRはDiscourseチームの誰かによる最終レビュー待ちで、約8週間経ちました。予想よりもかなり長いように思えます。

github.com/discourse/discourse

FEATURE: Add probe-only functionality to SSO Provider protocol

main ← mdoggydog:maddog-sso-provider-probe-only

opened 07:36PM - 03 Jul 23 UTC

mdoggydog

+88 -7

This commit adds support for an optional "probe" parameter in the payload of the… /session/sso_provider endpoint. If an SSO Consumer adds a "probe=true" parameter to the encoded/signed "sso" payload, then Discourse will avoid trying to login a not-logged-in user: * If the user is already logged in, Discourse will immediately redirect back to the Consumer with the user's credentials in a signed payload, as usual. * If the user is not logged in, Discourse will immediately redirect back to the Consumer with a signed payload bearing the parameter "failed=true". This allows the SSO Consumer to simply test whether or not a user is logged in, without forcing the user to try to log in. This is useful when the SSO Consumer allows both anonymous and authenticated access. (E.g., users that are already logged-in to Discourse can be seamlessly logged-in to the Consumer site, and anonymous users can remain anonymous until they explicitly ask to log in.)

david · 2023 年 9 月 28 日午前 11:54

@mdoggydog 様 - ご連絡が大変遅くなり申し訳ありません！

PRを確認し、マージしました。貢献ありがとうございます！

mdoggydog · 2023 年 9 月 28 日午後 4:31

やった！ @davidさん、ありがとうございます。

お約束通り、新しいパラメータの説明（および以前の新しい logout パラメータの説明）を含めるように、ここにウィキ記事を更新しました。また、軽微な誤字脱字/文法の間違いを修正し、ソースコードを調べた結果理解した sso= ペイロードを文書化する参照セクションを追加しました。

alehandrof · 2023 年 12 月 7 日午後 4:32

Discourse の SSO にウェブサイトを使用するのをやめ、Discourse の組み込みログインツールを使用してウェブサイト上の特定の資料へのアクセスを制限したいと考えています。

使用するのに適したツールは次のとおりだと思います: GitHub - discourse/discourse-auth-proxy: An http proxy that uses the DiscourseConnect protocol to authenticate users

これを使用するための詳細な手順が見つかりませんでした。

Discourse サイトと同じ DigitalOcean ドロップレットにインストールできますか、それともどこか別の場所にホストする必要がありますか？

編集: 質問を太字にしました

alehandrof · 2023 年 12 月 18 日午後 5:11

上記の質問について、何かお手伝いできることはありますか？ Use Discourse as an identity provider (SSO, DiscourseConnect) - #148 by alehandrof

uckelman · 2024 年 2 月 17 日午前 11:36

return_sso_url として、それ自体にクエリパラメータを持つ URL を設定しています。

http://localhost:7000/completeLogin?returnto=%2F

sso パラメータとして /session/sso_provider に送信するペイロードは、base64 エンコード前は次のようになります。

nonce=ENIwf0bElViDu325dTd6&return_sso_url=http://localhost:7000/completeLogin?returnto=%2F

認証後に Discourse が実際にリダイレクトする URL は次のようになります（sso と sig パラメータは省略されています）。

http://localhost:7000/completeLogin?returnto=/\u0026sso=...\u0026sig=...

ここで驚くべきは、return_sso_url のクエリ文字列が何かによって URL デコードされたように見えることです。なぜなら、returnto=%2F の代わりに returnto=/ になっているからです。base64 デコード後の sso 内の return_sso_url の値も、%2F の代わりにスラッシュになっています。

これは予期される動作でしょうか？（もしそうなら、なぜでしょうか？）これは Discourse のバグでしょうか？

uckelman · 2024 年 2 月 17 日午後 6:05

sso ペイロードに /u/{username}.json および /session/current.json で返される avatar_template の代わりに avatar_url が含まれている理由は何ですか？

avatar_url はアバターを設定していないユーザーには存在しませんが、avatar_template には、アバターを設定していないユーザーのアバターを表示するために Discourse で実際に使用される leter_avatar_proxy パスが含まれています。また、アバターを設定しているユーザーの場合、avatar_url は、希望するサイズにスケーリングされたものではなく、生の画像へのパスを指します。

sso に含まれるアバター情報を使用したい人は誰でも avatar_template を必要とするように思えますが、その場合、取得するために追加の API リクエストを行う必要があります。

perryflynn · 2024 年 9 月 24 日午後 6:41

現在、アプリにSSOを実装していますが、ログインはうまくいっていますが、ログアウトがうまくいきません。

私のDiscourseインスタンスは、ssoまたはsigパラメータなしでリダイレクトURLに正しくリダイレクトされますが、Discourseを開くと、アカウントはまだログインしたままです。

何か考えはありますか？

simon · 2024 年 9 月 24 日午後 7:39

Discourseからログアウトした後にユーザーをアプリにリダイレクトするために、Discourseのlogout redirectサイト設定を使用していると仮定します。

問題の可能性のある原因は、Discourseサイトでlogin required設定が有効になっている場合です。この設定が有効になっている場合、ユーザーがDiscourseサイトに直接アクセスした場合、Discourseは自動的にSSOプロバイダーサイトにリダイレクトします。つまり、logout redirect URLに最初にリダイレクトされたときにアプリからユーザーをログアウトしない限り、次回サイトにアクセスしたときにDiscourseに自動的にログインされます。ブラウザのインスペクターを開いてネットワークタブを表示した状態でこのプロセスを実行することで、この動作を確認できます。

参考までに、WP DiscourseプラグインがDiscourseのログアウトリダイレクトを処理する方法を以下に示します: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub

トピック		返信	表示
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) Integrations sso , discourseconnect , configuring , how-to	42	450713	2025 年 11 月 13 日
Integration into custom auth system where emails are not unique? SSO email	40	1180	2024 年 6 月 6 日
Configure single sign-on (SSO) with WP Discourse and DiscourseConnect Administrators sso , wordpress , video , discourseconnect , how-to	19	5691	2025 年 11 月 24 日
Discourse a SSO provider for Wordpress WordPress	10	5756	2020 年 5 月 23 日
DiscourseConnect Provider Questions WordPress	38	2716	2023 年 10 月 5 日

Use Discourse as an identity provider (SSO, DiscourseConnect)

関連トピック