### Author:  [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [2014 年 2 月 25 日午前 8:30 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/1 "2014-02-25T08:30:34Z")
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) は、Discourse のコア機能の一つで、ユーザー登録とログインをすべて別のサイトに完全に委譲する「シングルサインオン（SSO）」を設定できるようにします。これは、[プロ、ビジネス、エンタープライズホスティングのお客様](https://discourse.org/pricing) に提供されています。
> ℹ （2021 年 2 月）「[Discourse SSO](https://meta.discourse.org/t/13045?silent=true)」は現在「[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true)」となっています。古いバージョンの Discourse を実行している場合、以下の設定名は `discourse_connect_...` ではなく `sso_...` となります。
### 問題点
Discourse サイトと連携しようとする多くのサイトでは、すべてのユーザー登録を別のサイトに保持したいと考えています。このような設定では、すべてのログイン操作をその異なるサイトに委譲する必要があります。
### 既存の認証と併用して SSO を使用したい場合はどうすればよいですか？
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) の目的は、Discourse の認証を置き換えることです。新しいプロバイダーを追加したい場合は、既存のプラグイン（例：[https://meta.discourse.org/t/vk-com-login-vkontakte/12987）を参照してください。](https://meta.discourse.org/t/vk-com-login-vkontakte/12987%EF%BC%89%E3%82%92%E5%8F%82%E7%85%A7%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82)
### [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) の有効化
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) を有効にするには、以下の 3 つの設定を記入する必要があります。
`enable_discourse_connect`：有効にする必要があります（グローバルスイッチ）
`discourse_connect_url`：ログイン時にユーザーが転送される **外部** URL
`discourse_connect_secret`：SSO ペイロードをハッシュ化するために使用される秘密の文字列。ペイロードの真正性を保証します。
`enable_discourse_connect` を true に設定すると、以下のようになります。
- ログインまたはアバターをクリックすると、`/session/sso` にリダイレクトされ、さらにユーザーが署名付きペイロードとともに `discourse_connect_url` にリダイレクトされます。
- ユーザーは「パスワードの変更」を行うことができません。このフィールドはユーザープロフィールから削除されます。
- ユーザーはもはや Discourse 認証（ユーザー名/パスワード、Google など）を使用できなくなります。
### 誤ってチェックしてしまった場合はどうすればよいですか？
参照：[Log back in as admin after locking yourself out with read-only mode or an invalid SSO configuration](https://meta.discourse.org/t/what-to-do-when-you-have-locked-yourself-out-by-invalid-sso-configuration-or-read-only-mode/89605)
### サイトでの [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) の実装
> ⚠ Discourse は、外部ユーザーを Discourse ユーザーにマッピングするために電子メールを使用し、外部電子メールが安全であると仮定しています。 **外部電子メールを Discourse に送信する前に検証していない場合、サイトは極めて脆弱になります！**
または、検証されていない電子メールを送信することを強く主張する場合は、 **必ず** `require_activation=true` を設定してください。これにより、すべての電子メールが Discourse によって検証されるようになります。ただし、この設定を有効にすることは **強く推奨されません** 。この設定を有効にして進める場合は、大きなリスクを引き受けることになります。
Discourse は、署名付きペイロードとともにクライアントを `discourse_connect_url` にリダイレクトします（例：`discourse_connect_url` が `https://somesite.com/sso` の場合）。
以下のような受信トラフィックを受け取ります。
`https://somesite.com/sso?sso=PAYLOAD&sig=SIG`
ペイロードは、[nonce](http://en.wikipedia.org/wiki/Cryptographic_nonce) と `return_sso_url` で構成される Base64 エンコードされた文字列です。ペイロードは常に有効なクエリ文字列です。
例えば、nonce が ABCD の場合、raw\_payload は以下のようになります。
`nonce=ABCD&return_sso_url=https%3A%2F%2Fdiscourse_site%2Fsession%2Fsso_login`。この raw\_payload は [Base64](http://en.wikipedia.org/wiki/Base64) エンコードされています。
呼び出されるエンドポイントでは、以下の処理を行う必要があります。
1. 署名を検証する：`discourse_connect_secret` を鍵として使用した `PAYLOAD` の HMAC-SHA256 が `sig` と等しいことを確認する（`sig` は hex エンコードされる）。
2. 必要な認証を実行する。
3. 少なくとも **nonce** 、 **email** 、 **external\_id** を含む新しい URL エンコードされたペイロードを作成する。追加データも提供可能で、Discourse が理解するすべてのキーのリストは以下の通りです。
- **nonce** は入力ペイロードからコピーする必要があります。
- **email** は検証済みの電子メールアドレスである必要があります。電子メールアドレスが検証されていない場合は、 **require\_activation** を「true」に設定してください。
- **external\_id** は、ユーザー固有の一意の文字列で、電子メールや名前などが変更されても決して変更されない値です。推奨値は、データベースの「id」行番号です。
- **username** は、ユーザーが新規の場合、または `SiteSetting.auth_overrides_username` が設定されている場合に、Discourse 上のユーザー名になります。
- **name** は、ユーザーが新規の場合、または `SiteSetting.auth_overrides_name` が設定されている場合に、Discourse 上のフルネームになります。
- **avatar\_url** は、ユーザーが新規の場合、または `SiteSetting.discourse_connect_overrides_avatar` が設定されている場合に、ダウンロードされてユーザーのアバターとして設定されます。
- **avatar\_force\_update** はブール値フィールドです。true に設定すると、`avatar_url` が変更されたかどうかに関わらず、Discourse がユーザーのアバターを更新することを強制します。
- **bio** は、ユーザーが新規の場合、またはユーザーのバイオが空の場合、または `SiteSetting.discourse_connect_overrides_bio` が設定されている場合に、ユーザーのバイオの内容になります。
- **title** は、ユーザーのタイトルを設定します。
- **website** は、ユーザーのプロフィール上のウェブサイトを設定します。
- **location** は、ユーザーのプロフィール上の所在地を設定します。
- **profile\_background\_url** は、ユーザーが新規の場合、または `SiteSetting.discourse_connect_overrides_profile_background` が設定されている場合に、ダウンロードされてユーザーのプロフィール背景として設定されます。
- **card\_background\_url** は、ユーザーが新規の場合、または `SiteSetting.discourse_connect_overrides_card_background` が設定されている場合に、ダウンロードされてユーザーのカード背景として設定されます。
- **locale** は、ユーザーが新規の場合、かつ `SiteSetting.allow_user_locale` が有効になっている場合に、ユーザーのロケールを設定します。
- **locale\_force\_update** はブール値フィールドです。 **locale** とともに true に設定すると、既存のユーザーのロケールを更新することを強制します（`SiteSetting.allow_user_locale` が必要）。
- 追加のブール値（「true」または「false」）フィールドには、 **admin** 、 **moderator** 、 **suppress\_welcome\_message** 、 **logout** があります。
4. ペイロードを Base64 エンコードする。
5. `discourse_connect_secret` を鍵として、Base64 エンコードされたペイロードをテキストとして HMAC-SHA256 ハッシュを計算する。
6. `sso` と `sig` クエリパラメータとともに `return_sso_url` にリダイレクトする（`http://discourse_site/session/sso_login?sso=payload&sig=sig`）。
Discourse は nonce が有効であることを検証し、有効であればすぐに期限切れにして再利用できないようにします。その後、以下の処理を試みます。
1. `SingleSignOnRecord` モデルで既に連携されている **external\_id** を検索してユーザーをログインさせる。
2. 提供された電子メールを使用してユーザーをログインさせる（ **require\_activation = true でない限り** ）。
3. ユーザーに対して新しいアカウントを作成する（email、username、name を提供し、external\_id を更新する）。
### セキュリティ上の懸念
nonce（ワンタイムトークン）は 30 分後に自動的に期限切れになります。つまり、ユーザーがサイトにリダイレクトされてから 30 分以内にログインまたは新規アカウントを作成する必要があります。
このプロトコルは、nonce は一度しか使用できないため、リプレイ攻撃に対して安全です。また、nonce は現在のブラウザセッションに紐付けられているため、CSRF 攻撃から保護されます。
### グループメンバーシップの指定
「[discourse connect](https://meta.discourse.org/t/13045?silent=true) overrides groups」オプションが指定されている場合、Discourse は `groups` に渡されたカンマ区切りのグループリストを考慮します。
`groups` 以外にも、SSO ペイロード内で `add_groups` と `remove_groups` 属性を使用してグループメンバーシップを指定できます。これは「[discourse connect](https://meta.discourse.org/t/13045?silent=true) overrides groups」オプションの有無に関係なく機能します。
`add_groups` は、ユーザーがメンバーであることを保証するグループ名のカンマ区切りリストです。
`remove_groups` は、ユーザーが **メンバーでない** ことを保証するグループ名のカンマ区切りリストです。
### リファレンス実装
Discourse には、SSO クラスのリファレンス実装が含まれています。
>
簡単な実装例は以下の通りです。
```ruby
class DiscourseSsoController < ApplicationController
def sso
secret = "MY_SECRET_STRING"
sso = DiscourseApi::SingleSignOn.parse(request.query_string, secret)
sso.email = "user@email.com"
sso.name = "Bill Hicks"
sso.username = "bill@hicks.com"
sso.external_id = "123" # アプリケーションの各ユーザー固有の ID
sso.sso_secret = secret
redirect_to sso.to_url("http://l.discourse/session/sso_login")
end
end
```
### シングルサインオンへの移行と移行後
リクエストペイロードで `require_activation` パラメータが `true` に設定されていない限り、システムはシングルサインオンエンドポイントから提供された電子メールを信頼します。つまり、過去に [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) が無効な状態で Discourse に既存のアカウントを持っていた場合、[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) はそれを再利用し、新しいアカウントを作成することはありません。
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) を無効にした場合、ユーザーはパスワードをリセットしてアカウントにアクセスできるようになります。
### 実例
以下の設定を想定します。
Discourse ドメイン：`http://discuss.example.com`
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) URL：`http://www.example.com/discourse/sso`
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) シークレット：`d836444a9e4084d5b224a60c208dce14`
電子メール検証：なし（ペイロードに `require_activation=true` を追加）
**ユーザーがログインを試みる**
- nonce が生成される：`cb68251eefb5211e58c00ff1395f0c0b`
- raw ペイロードが生成される：`nonce=cb68251eefb5211e58c00ff1395f0c0b`
- ペイロードが Base64 エンコードされる：`bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI=`
- ペイロードが URL エンコードされる：`bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D`
- Base64 エンコードされたペイロードに対して HMAC-SHA256 が生成される：`1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471`
最後に、ブラウザは以下にリダイレクトされます。
`http://www.example.com/discourse/sso?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D&sig=1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471`
**他端での処理**
1. ペイロードが HMAC-SHA256 を使用して **検証** される。sig が不一致の場合、処理は中止される。
2. 上記の手順を逆順に実行して nonce を抽出する。
ユーザーがログインする。
```plaintext
name: sam
external_id: hello123
email: test@test.com
username: samsam
require_activation: true
```
署名なしペイロードが生成される。
`nonce=cb68251eefb5211e58c00ff1395f0c0b&name=sam&username=samsam&email=test%40test.com&external_id=hello123&require_activation=true`
順序は関係なく、値は URL エンコードされます
ペイロードが Base64 エンコードされる。
`bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ==`
ペイロードが URL エンコードされる。
`bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D`
Base64 エンコードされたペイロードが署名される。
`3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3`
ブラウザは以下にリダイレクトされる。
`http://discuss.example.com/session/sso_login?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D&sig=3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3`
### [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) レコードの同期
POST 管理エンドポイント `/admin/users/sync_sso` を使用して [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) レコードを同期できます。[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) エンドポイントに渡すのと同じレコードを渡せばよく、nonce は関係ありません。
他のサイトから `admin/users/sync_sso` を呼び出す場合は、リクエストのヘッダーに有効な管理者 `api_key` と `api_username` を含める必要があります。リクエストの構造についての詳細は、[Sync DiscourseConnect user data with the sync\_sso route](https://meta.discourse.org/t/sync-discourseconnect-user-data-with-the-sync-sso-route/84398) を参照してください。
### [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) レコードの削除
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) プロバイダーからの `external_id` 値が変更された場合（生成アルゴリズムを変更した場合や、異なるエンドポイントの場合など）、Rails コンソールを使用して既存のレコードをすべて安全に削除できます。
```ruby
SingleSignOnRecord.destroy_all
```
### ユーザーのログアウト
必要に応じて、システム内の任意のユーザーをログアウトさせるために、POST 管理エンドポイント `/admin/users/{USER_ID}/log_out` を使用できます。
ログアウト時に Discourse がリダイレクトするエンドポイントを構成するには、「logout redirect」設定を検索してください。ここで URL が設定されていない場合、`discourse connect url` で設定された URL にリダイレクトされます。
### `external_id` によるユーザー検索
ユーザープロフィールデータは `/users/by-external/{EXTERNAL_ID}.json` エンドポイントを使用してアクセスできます。これにより、`user_id` を含むユーザー情報を含む JSON ペイロードが返されます。この `user_id` は `log_out` エンドポイントで使用できます。
### 既存の実装
- [`discourse_api` gem](https://github.com/discourse/discourse_api) を SSO に使用できます。基本的な実装を確認するには、[examples ディレクトリ](https://github.com/discourse/discourse_api/tree/master/examples) の SSO コードを参照してください。
- [WordPress プラグイン](https://wordpress.org/plugins/wp-discourse/) を使用すると、WordPress と Discourse 間の SSO 設定が簡単になります。設定の詳細は、プラグインのオプションページの SSO タブにあります。
### 今後の課題
- 他のプラットフォーム向けの SSO のリファレンス実装をさらに収集したいと考えています。実装をお持ちの場合は、[Dev / SSO カテゴリー](https://meta.discourse.org/c/sso/24) に投稿してください。
### 高度な機能
- フィールド名の前に `custom` をプレフィックスすることで、カスタムユーザーフィールドを渡すことができます。例えば、`custom.user_field_1` は、名前が `user_field_1` の `UserCustomField` の値を設定するために使用できます。
- `avatar_url` を渡してユーザーのアバターを上書きできます（`SiteSetting.discourse_connect_overrides_avatar` を有効にする必要があります）。アバターはキャッシュされるため、URL が同じでも更新を強制するには `avatar_force_update=true` を渡してください。現在、ユーザーのアバターを無効にするために空の URL を渡すことはできません。
- デフォルトでは、SSO 経由で作成されたすべての新規ユーザーにウェルカムメッセージが送信されます。これを抑制したい場合は、`suppress_welcome_message=true` を渡してください。
- Discourse インスタンスを [Discourse Connect](https://meta.discourse.org/t/13045?silent=true) プロバイダーとして設定するには、[DiscourseConnect をアイデンティティプロバイダーとして使用する](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974) を参照してください。
### [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) プロバイダーのデバッグ
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) のデバッグを支援するために、サイト設定 `verbose_discourse_connect_logging` を有効にできます。この設定を有効にすると、`YOURSITE.com/logs` に詳細な診断情報が表示されます。`YOURSITE.com/logs` の下部にある「warnings」ボックスに ✅ することをお忘れなく。
SSO ペイロードの完全なダンプを含む警告をログに記録します。
- [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) プロセスが開始されるたびに、[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) ペイロードの完全なダンプを含む警告をログに記録します。
- ユーザーが [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) の完了に失敗するたびに（nonce の期限切れや IP ブロックによる）
> 🗒 ユーザーのサインアップを自動化する必要がありますか？[Auto-provisioning user accounts when SSO is enabled](https://meta.discourse.org/t/auto-provisioning-user-accounts-when-sso-is-enabled/399917) を参照してください。
---
### Author:  [@dennisjbr](https://meta.discourse.org/u/dennisjbr)
#### Post date: [2024 年 8 月 30 日午後 10:19 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/579 "2024-08-30T22:19:12Z")
こんにちは、どこで見つけるのが難しいのですが、これはどのプロトコルを使用していますか？ OAuth2 を想定していますか？ パラメータが一致しないようで、プロバイダーから sso= パラメータを受け入れているように見えるというエラーが発生しますか？ ヘルプ！
ありがとう
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [2024 年 8 月 31 日午前 10:49 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/580 "2024-08-31T10:49:26Z")
> [@dennisjbr](#):
>
> これはどのプロトコルを使用しますか？
[DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) は Discourse の SSO の実装です。標準プロトコルは使用しません。
PHP コードを見てもよければ、ここに実装例があります: [wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub](https://github.com/discourse/wp-discourse/blob/main/lib/sso-provider/discourse-sso.php).
> [@dennisjbr](#):
>
> OAuth2 を想定していますか？パラメータが一致しないようです
ええ、それはうまくいきません。ユーザー認証に使用したい OAuth2 プロバイダーがある場合は、[Discourse OAuth2 Basic](https://meta.discourse.org/t/discourse-oauth2-basic/33879) プラグインを見てみてください。
---
### Author:  [@dennisjbr](https://meta.discourse.org/u/dennisjbr)
#### Post date: [2024 年 8 月 31 日午後 6:26 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/581 "2024-08-31T18:26:58Z")
@simon 様、ありがとうございます。PHPコードもプロバイダーであり、コンシューマーではないということでしょうか？また、プラグインエリアにあるOIDCプロバイダーも機能する可能性があり、「中間業者」プロバイダーも見かけました。
SSOプロバイダーが標準的でない場合、他のものと連携しないのであれば、誰/何のために意図されているのでしょうか？
重ねてお礼申し上げます！
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [2024 年 8 月 31 日午後 9:30 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/582 "2024-08-31T21:30:39Z")
> [@dennisjbr](#):
>
> PHPコードもプロバイダーであり、コンシューマーではないのですか？
私がリンクしたコードは、WordPressをDiscourseの認証プロバイダーとして使用するためのものです。
WordPressプラグインは、WordPressをDiscourseConnectクライアントとしても使用できるようにします: [wp-discourse/lib/sso-client at main · discourse/wp-discourse · GitHub](https://github.com/discourse/wp-discourse/tree/main/lib/sso-client).
> [@dennisjbr](#):
>
> SSOプロバイダーが標準でない場合、誰/何のために意図されているのですか？
DiscourseにカスタムSSO実装を追加した動機は不明です。ビジネス上の理由があったのだと推測します。
その利点の1つは、外部サイトをDiscourseと緊密に統合できることです。たとえば、ここにリストされているすべてのユーザー属性は、認証プロセス中にDiscourseと同期できます: [discourse/lib/discourse\_connect\_base.rb at 7b89fdead98606d4f47ceb0a1d240d0f6e5f589e · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/7b89fdead98606d4f47ceb0a1d240d0f6e5f589e/lib/discourse_connect_base.rb#L13-L43).
また、OAuth2またはOpenID Connectプロバイダーとして設定されていないサイトでも、Discourseでユーザーを認証するために使用できます。
欠点は、認証プロバイダーサイトにカスタムコードを追加する必要があることです。
---
### Author:  [@eric\_wa](https://meta.discourse.org/u/eric_wa)
#### Post date: [2024 年 9 月 10 日午後 8:11 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/583 "2024-09-10T20:11:38Z")
SSOを提供する外部サイトでメールアドレスを確認しないことによる問題について教えてください。自動スパムを可能にするだけですか？それとも他に考慮すべき点はありますか？外部サイトがメールアドレスを確認しない場合、Discourseがメールアドレス確認を処理しないことが推奨されないのはなぜですか？
追加の洞察があれば教えてください。
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [2024 年 9 月 12 日午前 5:24 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/584 "2024-09-12T05:24:50Z")
> [@eric\_wa](#):
>
> これは、自動的なスパム送信を可能にするということだけですか？
私が知る限り、最悪のシナリオは以下の条件を必要とします。
- 外部サイトでメールアドレスが検証されていない
- SSOペイロードで `require_activation=true` が設定されていない
- Discourseサイトに `SingleSignOnRecord` が関連付けられていない既存のアカウントがある（アカウント所有者がDiscourseにSSOでログインしたことがない）
この場合、SSOでログインしたことがないDiscourseユーザーのメールアドレスを使用して、外部サイトでサインアップすることができます。これにより、外部サイトの未検証アカウントが、同じメールアドレスを使用しているDiscourseアカウントを乗っ取ることが可能になります。これは、Discourse上の管理者アカウントの場合、特に懸念されるでしょう。
> [@eric\_wa](#):
>
> 外部サイトがメール検証を行わない場合、Discourseがメール検証を処理しないことが推奨されないのはなぜですか？
外部サイトがメール検証を処理しない場合は、Discourseがメール検証を処理することが推奨されます。
> [@Discourse](#):
>
> あるいは、検証されていないメールを送信することを主張する場合は、 **必ず** `require_activation=true` を設定してください。これにより、すべてのメールがDiscourseによって検証されるようになります。 **それでもこの設定は推奨しません。** そのため、この設定を有効にして続行する場合は、かなりのリスクを負うことになります。
ただし、メール検証を外部サイトで処理する方が良いのには、いくつかの理由があります。
- ユーザーにDiscourseからの確認メールを受信させることは、ユーザーが初めてDiscourseにログインしようとするときのわずかな手間になります。（現実的には、その手間はどこかで発生する必要があります。Discourse側か、外部サイト側のどちらかです。）
- SSOペイロードで `require_activation` が `true` に設定されている場合、Discourseは既存のDiscourseアカウントをメールアドレスに基づいて外部ログインと一致させません。これは、ユーザー名/パスワードで登録してDiscourseにアカウントが作成された後にDiscourseConnectを有効にした場合に問題となります。また、何らかの理由でDiscourse上の `SingleSignOnRecord` エントリを削除する必要がある場合にも問題となります。ユーザーがDiscourseに再度ログインしようとしても、Discourseは自動的に新しい `SingleSignOnRecord` エントリを作成しません。
---
### Author:  [@eric\_wa](https://meta.discourse.org/u/eric_wa)
#### Post date: [2024 年 9 月 12 日午後 3:07 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/585 "2024-09-12T15:07:34Z")
ありがとうございます、@simon さん。大変参考になります！
---
### Author:  [@GregorSondermeier](https://meta.discourse.org/u/GregorSondermeier)
#### Post date: [2024 年 12 月 17 日午後 12:53 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/586 "2024-12-17T12:53:57Z")
こんにちは。SSOペイロードの`groups`フィールドについて質問があります。
> [@Discourse](#):
>
> ### グループメンバーシップの指定
>
> _[Discourse Connect](https://meta.discourse.org/t/13045?silent=true)がグループを上書きする_オプションが指定されている場合、Discourseは`groups`で渡されたコンマ区切りのグループリストを考慮します。
>
> 
管理者、モデレーター、信頼レベルなどの自動グループも上書きされますか？それとも保持されますか？
---
### Author:  [@Firepup650](https://meta.discourse.org/u/Firepup650)
#### Post date: [2024 年 12 月 17 日午後 1:02 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/587 "2024-12-17T13:02:09Z")
> [@GregorSondermeier](#):
>
> 自動化されたグループ（管理者、モデレーター、信頼レベルなど）も上書きされますか？
いいえ！その設定の説明が正しければ、_手動_グループのみに影響します。
---
### Author:  [@GregorSondermeier](https://meta.discourse.org/u/GregorSondermeier)
#### Post date: [2024 年 12 月 18 日午前 6:33 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/588 "2024-12-18T06:33:29Z")
「マニュアル」という言葉が説明になかったので、私の用途には有望そうです。試してみて、また報告します。
---
### Author:  [@probablykasper](https://meta.discourse.org/u/probablykasper)
#### Post date: [2024 年 12 月 21 日午前 7:24 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/589 "2024-12-21T07:24:58Z")
これを読んだとき、Base64エンコードされたペイロードから直接署名を生成するものだと思っていました。UTF-8バイトから生成する必要があることに気づきませんでした。この点を明確にしていただけますか？
---
### Author:  [@martyn\_thomas](https://meta.discourse.org/u/martyn_thomas)
#### Post date: [2024 年 12 月 26 日午後 1:29 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/590 "2024-12-26T13:29:25Z")
DiscourseConnectを試しています。ドキュメントは素晴らしいです、ありがとうございます。
しかし、いくつか問題にぶつかりました。いくつか助けや説明をいただけると幸いです。
WordPressのDiscourseログインでログインできるようにしたいと考えています（これはうまくいっています :)）。しかし、
- Discourseのサインアップ経由でWordPressユーザーを作成することは可能ですか？（ユーザーがDiscourseユーザーアカウントを作成したときに、自動的にWordPressアカウント/プロファイルも作成され、WordPressにログインできるようになりますか？）
- WordPressユーザーグループとDiscourseグループを同期することは可能ですか？
ユーザーがWordPressとDiscourseの両方のユーザーアカウントを持っている場合、DiscourseConnectはそれらを結合できますが、WordPressアカウントに同じ名前のDiscourseグループのユーザーグループを付与しません。また、その逆も同様です。（グループ名が同じでない場合はどうなりますか？ユーザーが「テスト用グループ」というDiscourseグループを持っている場合に、「テストグループ」というユーザーグループをDiscourseConnectに付与するように指示するにはどうすればよいですか？）
何が足りないのでしょうか？
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [2024 年 12 月 26 日午後 3:25 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/591 "2024-12-26T15:25:57Z")
わかりませんが…
> [@martyn\_thomas](#):
>
> WordPressのアカウント/プロフィールが自動的に作成されます
注意してください。それは違法な場所であり、サイト所有者以外にとっては広く悪い習慣と見なされています（もちろん😏）、なぜならそれはユーザーの同意と認識なしに起こり、同時にデータがどこかに移動するからです。
確かに、それはいくらかグレーゾーンであり、基本的に、例えばGoogleもそれをやっています。
しかし…なぜですか？ WordPress側でDiscourse SSOのみにログインを制限し、ユーザーをDiscourseにリダイレクトしてアカウントを作成すればそれで終わりです。しかし、私の知る限り、ユーザーアカウントを標準で自動的に同期することはできません。そして、なぜそうする必要があるのか、SSOがあればユーザーが必要なときに発生するからです。
---
### Author:  [@martyn\_thomas](https://meta.discourse.org/u/martyn_thomas)
#### Post date: [2024 年 12 月 26 日午後 4:06 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/592 "2024-12-26T16:06:22Z")
私たちのシナリオでは（会員制組織として）
- WordPressはサブスクリプションの管理、WordPressストアでの商品の購入に使用され、User Groupsを使用して組織内で会員ができることを管理しています。
- Discourseはフォーラム/オンラインコミュニティであり、Groupsを使用してユーザーがDiscourseのどのエリアにアクセスできるかを制御しています。
現在、新規会員はWordPressアカウント（サブスクリプションなどの設定を含む）とDiscourseアカウントの両方を設定する必要があり、User GroupとDiscourse Groupは手動で管理/同期されています。
新規ユーザーが一度の設定で両方のアカウントを作成でき、User GroupとDiscourse Groupが自動的に同期されるソリューションを探しています。グループ同期についてはAPIなどで解決できると思いますが、複数のユーザーアカウント設定を解決/回避したいと考えています。
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [2024 年 12 月 27 日午前 8:06 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/593 "2024-12-27T08:06:04Z")
> [@martyn\_thomas](#):
>
> DiscourseのログインでWordPressにログインできるようにしたいのです。
それは、DiscourseをWordPressのSSOプロバイダーとして使用しているということのようですね。そのアプローチについては、こちらに概要が記載されています。[DiscourseをIDプロバイダー（SSO、DiscourseConnect）として使用する](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974)。Discourse WordPressプラグインには、WordPressをDiscourseのSSOプロバイダーとして使用するか、DiscourseをWordPressのIDプロバイダーとして使用するかを選択するオプションがあります。両方のアプローチで同じ名前を使用すると、混乱が生じます。
> [@martyn\_thomas](#):
>
> 私たちのシナリオ（会員制組織として）では
>
> - WordPressはサブスクリプションの管理、WordPressストアでの商品の購入に使用し、ユーザーグループを使用して会員が組織内で何ができるかを管理しています。
> - Discourseはオンラインコミュニティ/フォーラムであり、グループを使用してユーザーがDiscourseのどのエリアにアクセスできるかを制御しています。
この場合、WordPressをIDプロバイダーとして使用することをお勧めします。このアプローチでは、ユーザーはWordPressサイトでアカウントを作成し、WordPressの認証情報でDiscourseにログインします。このアプローチで注意すべき点は、ユーザーがDiscourseにログインできるのはWordPress経由のみであり、WordPressアカウントなしでDiscourseアカウントを作成することはできないということです。DiscourseをWordPress会員サイトと統合する場合、これは適切な設定だと思います。
WordPressをDiscourseのIDプロバイダーとして使用する場合、WordPressでのアクティビティに基づいてユーザーのDiscourseグループメンバーシップを設定するのに役立つユーティリティ関数がいくつかあります。これらの関数については、こちらに概要が記載されています。[WP Discourse SSOでDiscourseのグループメンバーシップを管理する](https://meta.discourse.org/t/manage-group-membership-in-discourse-with-wp-discourse-sso/74724)。
元の質問に戻ります。
> [@martyn\_thomas](#):
>
> DiscourseのログインでWordPressにログインできるようにしたいのです（これはうまくいっています 🙂 ） - しかし。
>
> - DiscourseのサインアップからWordPressユーザーを作成することは可能ですか（ユーザーがDiscourseユーザーアカウントを作成したときに、WordPressアカウント/プロファイルも自動的に作成され、WordPressにログインできるようになりますか）？
WordPressプラグインのDiscourseConnectクライアントコードを確認してからしばらく経ちますが、あなたが求めていることは、そのコードが期待どおりに動作する、おおよそそのようになっていると思います。ユーザーがDiscourseアカウントを持っている場合、WordPressの「Discourseでログイン」リンクをクリックするだけでアカウントが作成されます。
> [@martyn\_thomas](#):
>
> WordPressユーザーグループとDiscourseグループを同期することは可能ですか？
これは、WordPressをDiscourseConnectクライアントとして使用する場合、技術的には可能ですが、何か変更されていない限り、ドキュメントで説明されている `add_user_to_discourse_group` および `remove_user_from_discourse_group` メソッドを使用することはできません。Discourseグループにユーザーが追加されたときにトリガーされるDiscourse Webhookを設定し、WordPressにそのWebhookを処理するコードを追加する必要があります。WordPressからDiscourseにグループを同期するには、WordPressで変更があったときにユーザーのグループを更新するためにDiscourseにAPI呼び出しを行う必要があります。したがって、WordPressをDiscourseConnectプロバイダーとして使用する場合に比較的簡単に達成できることは、WordPressをDiscourseConnectクライアントとして使用する場合にはやや複雑になる可能性があります。
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [2024 年 12 月 27 日午前 8:48 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/594 "2024-12-27T08:48:16Z")
> [@simon](#):
>
> ユーザーがDiscourseアカウントを持っている場合、WordPressの「Discourse経由でログイン」リンクをクリックするだけでアカウントが作成されます。
カスタムログインが使用されている場合を除きます。これは通常、WooCommerce/メンバーシップ/LLMでそのボタンが表示され、Discourse SSOのみを使用するように強制することが標準では行われず、カスタム作業が必要な状況です。
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [2024 年 12 月 28 日午前 8:32 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/595 "2024-12-28T08:32:45Z")
> [@Jagster](#):
>
> WooCommerce/memberships/LLMで通常行われるカスタムログインが使用されている場合を除きます。
考えられる問題がいくつかあります。1つはキャッシュに関連する問題、もう1つは一部のプラグインによって追加されるログインリダイレクトに関連する問題です。これらの問題に遭遇した場合は、#Support > WordPress カテゴリで質問してください。通常は簡単に解決できます。
---
### Author:  [@GregorSondermeier](https://meta.discourse.org/u/GregorSondermeier)
#### Post date: [2025 年 1 月 9 日午前 7:54 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/596 "2025-01-09T07:54:47Z")
報告するのを完全に忘れていました。説明どおりに機能し、手動グループのみが影響を受けます。
---
### Author:  [@Michael\_Liu](https://meta.discourse.org/u/Michael_Liu)
#### Post date: [2025 年 3 月 21 日午前 5:20 UTC](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/597 "2025-03-21T05:20:20Z")
こんにちは @simon さん、
このSSO機能のPOC（概念実証）での404エラーについて、助けが必要だと思います。この問題に一日中取り組んでいますが、まだ原因を特定できていません。以下のことはできました。
1. discourse\_connect を有効化
2. discourse\_connect\_url を https:/ /localhost:4200/login に設定
3. discourse-connect secret: 20’s (1) 1111111111111111111 （単純にするため）
その後、Angularアプリのログインページで、以下のコードに従ってリクエストを送信しました。
しかし、404 Not Found という応答が返ってきました。
私の理解では、`admin/users/sync_sso` エンドポイントにPOSTリクエストを送信する際、ユーザーがDiscourseに存在しない場合は、`user_id` と `email` に基づいて新しいユーザーを作成し、返される結果は空のオブジェクトではなく、ユーザーオブジェクトであるべきです。ステータスコードは404ではありません。
ログも確認しましたが、この失敗した応答に関連する情報は提供されていませんでした。
よろしくお願いします！
[Next page](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045.md?page=2)