# Discourse をプロバイダーとして複数の SSO 秘密鍵をサポート

**URL:** <https://meta.discourse.org/t/supporting-multiple-sso-secrets-with-discourse-as-provider/96693>\
**Category:** Feature\
**Tags:** sso, discourseconnect\
**Created:** [2018 年 9 月 8 日午前 1:27 UTC](https://meta.discourse.org/t/supporting-multiple-sso-secrets-with-discourse-as-provider/96693 "2018-09-08T01:27:44Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\
**Post date:** [2018 年 9 月 10 日午前 6:32 UTC](https://meta.discourse.org/t/supporting-multiple-sso-secrets-with-discourse-as-provider/96693/3 "2018-09-10T06:32:33Z")

</div>

I think it is a bit overdue to make `sso_secret` single use vs “multi use” where it works both for incoming and outgoing SSO.

If we are cleaning this up I think we should probably clean it up all the way. Add a site setting for `sso_provider_secrets` which contains a list of pairs:

```plaintext
www.somewhere.com|SOME_LONG_SECRET
*.discourse.cloud|SOME_OTHER_LONG_SECRET

```

Etc… @j.jaffeux new control makes creating settings like this super easy ❤ but we would need a special mode where it hides the secrets in the UX like we do for other passwordish fields in site settings.

Then we also get extra security here cause even if a key leaks out it can only be used on the “domain” you allowed it so it will simply (post login) redirect to a non-hijacked URL which would be confused about the whole thing cause a NONCE would not check out.

Overall there is not too much work in this change and I totally support it cause it makes SSO provider support way cleaner and will force people using this feature to do a nice audit.

---

_[View the full topic](https://meta.discourse.org/t/supporting-multiple-sso-secrets-with-discourse-as-provider/96693)._