# Unterstützung mehrerer SSO-Geheimnisse mit Discourse als Anbieter

**URL:** <https://meta.discourse.org/t/supporting-multiple-sso-secrets-with-discourse-as-provider/96693>\
**Category:** Feature\
**Tags:** sso, discourseconnect\
**Created:** [8. September 2018 um 01: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:** 2

<div class="post-metadata">

**Author:** ![mpalmer](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mpalmer/32/45740_2.png) [@mpalmer](https://meta.discourse.org/u/mpalmer)\
**Post date:** [8. September 2018 um 04:57 UTC](https://meta.discourse.org/t/supporting-multiple-sso-secrets-with-discourse-as-provider/96693/2 "2018-09-08T04:57:14Z")

</div>

I am quite a fan of key agility, and this provides a mechanism to do that (at least the “do it properly” approach). I think the quick hack method is a really bad idea, for several reasons:

- You’d presumably have to be sending out both signatures all the time, which is wasteful for all those clients not requiring the extra signature;
- `k+consumer.hostname` is equivalent to `k` in any circumstance in which the attacker can influence the value of `consumer.hostname`.
- Conversely, even getting agreement between consumer and provider on what `consumer.hostname` even _is_ can be… an adventure, and the ways that are typically easier to do are also more amenable to attacker influence.
- The construction `hash(k+consumer.hostname)` would have to be carefully evaluated against possible attacks, which is a non-trivial exercise. There are _extremely_ good reasons why `HMAC(K, m)` is defined as `H((K' xor opad) || H((K' xor ipad) || m))`, and not just `H(K || m)`. Cryptography Is Hard.

---

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