# Usar Discourse como provedor de identidade (SSO, DiscourseConnect)
**URL:** https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974
**Category:** Integrations
**Tags:** sso, discourseconnect, how-to
**Created:** [7 Setembro , 2015 09:19 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974 "2015-09-07T09:19:21Z")
**Posts on this page:** 20
**Page:** 7
### Author:  [@cookieman768](https://meta.discourse.org/u/cookieman768)
#### Post date: [26 Janeiro , 2022 05:09 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/127 "2022-01-26T05:09:49Z")
Consegui usar isso para criar um sistema de vinculação de contas para o meu servidor do Minecraft! Pensei em compartilhar como ficou! Esta foi minha primeira vez trabalhando com [Discourse SSO](https://meta.discourse.org/t/13045?silent=true), então talvez eu tenha complicado tudo. No entanto, funciona, que é o principal.
[https://p185.p2.n0.cdn.getcloudapp.com/items/OAu449Gx/a02ec18d-3717-434e-a1d4-f9dbc6d1d8af.mp4](https://p185.p2.n0.cdn.getcloudapp.com/items/OAu449Gx/a02ec18d-3717-434e-a1d4-f9dbc6d1d8af.mp4)
---
### Author:  [@Devarsh\_Mavani](https://meta.discourse.org/u/Devarsh_Mavani)
#### Post date: [12 Junho , 2022 10:23 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/128 "2022-06-12T10:23:26Z")
Olá, fiz tudo isso corretamente. mas quando o usuário não está logado no discourse, ele mostra um pop-up de login do usuário. quando preencho nome de usuário e senha, ele não me redireciona de volta para o return\_url. você pode me ajudar?
---
### Author:  [@mksafi](https://meta.discourse.org/u/mksafi)
#### Post date: [28 Julho , 2022 23:01 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/129 "2022-07-28T23:01:46Z")
Presumo que o `nonce` esteja lá para prevenir _ataques de repetição_. Li online que ataques de repetição não são possíveis com HTTPS, que é o que estou usando. Então, ainda preciso fazer o nonce? Pergunto porque não tenho certeza de onde armazená-lo. Faz sentido armazená-lo como um cookie seguro e em texto simples no navegador do usuário? e depois lê-lo do navegador junto com o payload de retorno?
Esta biblioteca, que está vinculada à postagem original [GitHub - ArmedGuy/discourse\_sso\_node: npm package for Discourse SSO login features.](https://github.com/ArmedGuy/discourse_sso_node) não usa o nonce ao validar o usuário.
---
### Author:  [@Osama](https://meta.discourse.org/u/Osama)
#### Post date: [29 Julho , 2022 02:40 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/130 "2022-07-29T02:40:44Z")
> [@mksafi](#):
>
> Presumo que o `nonce` esteja lá para evitar _ataques de repetição_. Li online que ataques de repetição não são possíveis com HTTPS, que é o que estou usando. Então, eu ainda preciso fazer o nonce?
Sim, você ainda precisa validar o nonce porque ele impede o reuso de cargas úteis que o Discourse envia ao redirecionar usuários de volta para o seu site.
Por exemplo, digamos que seu site tenha algum conteúdo protegido por paywall que apenas membros do grupo `subscribers` no Discourse podem acessar e você usa o campo `groups` na carga útil que o Discourse envia para o seu site para exibir o conteúdo pago apenas para membros do grupo `subscribers`. Se você não validar o nonce, um usuário que não faz mais parte dos `subscribers` poderia usar uma carga útil antiga de quando ele era membro para fazer login no seu site e ver o conteúdo pago.
> [@mksafi](#):
>
> Faz sentido armazená-lo como um cookie seguro em texto simples no navegador do usuário? e então lê-lo do navegador junto com a carga útil de retorno?
É melhor armazenar o nonce em um banco de dados com uma data de expiração curta e excluir o nonce do banco de dados assim que ele for usado. No entanto, se você não puder usar um banco de dados, poderá usar um cookie para armazenar o nonce, mas precisará fazer algumas etapas adicionais para evitar o reuso da carga útil:
1. anexe uma data de expiração ao nonce quando você o gerar, por exemplo, 10 minutos a partir do momento atual
2. assine todo o cookie (nonce + data de expiração) para impedir que os usuários modifiquem o nonce e/ou a data de expiração
3. verifique a assinatura do cookie e certifique-se de que o nonce não expirou
Isso lhe dará proteção suficiente contra o reuso da carga útil. Tenha em mente que tecnicamente ainda é possível reutilizar uma carga útil, mas será limitada a uma janela de 10 minutos em vez de para sempre.
Uma solução mais simples que não precisa de um cookie é incluir a data de expiração em um [campo personalizado](https://github.com/discourse/discourse/blob/6849775a2db32b1c2c8f4ae84f7e7288d5008a9e/lib/discourse_connect_base.rb#L100-L104) na carga útil que você gera. Então, quando o Discourse redirecionar os usuários de volta para o seu site com uma carga útil, seus campos personalizados serão incluídos e você poderá recuperar a data de expiração e verificar se ela não expirou. Para incluir um campo personalizado na carga útil, você precisa incluir um campo prefixado com `custom.`, então sua carga útil ficaria assim:
```plaintext
nonce=NONCE&return_sso_url=RETURN_URL&custom.expiration_date=TIMESTAMP
```
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [29 Julho , 2022 06:21 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/131 "2022-07-29T06:21:30Z")
Você também pode armazenar o nonce na sessão, o que impedirá que o usuário o manipule também.
---
### Author:  [@EGreg](https://meta.discourse.org/u/EGreg)
#### Post date: [21 Agosto , 2022 21:13 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/132 "2022-08-21T21:13:00Z")
Voltando a este tópico anos depois
Alguém pode me dizer (@pfaffman ou @tobiaseigen ou @iamntz) o que o provedor [Discourse SSO](https://meta.discourse.org/t/13045?silent=true) retorna? Eu sei que posso “tentar e ver”, mas seria bom ter isso documentado. O código de exemplo PHP do GitHub nem sequer menciona outros campos.
Idealmente, ele enviaria os mesmos campos que quando o Discourse usa o script externo para SSO, como ID externo, e-mail, nome de usuário, nome, foto de avatar, etc. Assim, podemos importar isso e criar um usuário do nosso lado!
> **[How To Integrate Discourse Forum With WordPress: 2025 Guide](https://wpism.com/integrate-discourse-wordpress/)**
>
> Learn how to integrate your Discourse Forum with WordPress blog in this tutorial - Installing Discourse WordPress Plugin and configuring the settings.
Ele também informa o e-mail ao WordPress?
E quanto a grupos, distintivos, etc.? Podemos encontrar essas informações fazendo chamadas REST?
Finalmente, e quanto às mensagens privadas do usuário e outras coisas? Acho que se o Discord fosse um provedor oAuth e permitisse que nossos aplicativos consumissem essas coisas, seria incrível.
---
### Author:  [@Roie\_Natan](https://meta.discourse.org/u/Roie_Natan)
#### Post date: [15 Dezembro , 2022 02:15 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/136 "2022-12-15T02:15:09Z")
Ao tentar habilitar o [Discourse Connect](https://meta.discourse.org/t/13045), recebo este erro:
`enable_discourse_connect: Você não pode habilitar DiscourseConnect e convite apenas ao mesmo tempo.`
Alguma ideia?
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [15 Dezembro , 2022 04:49 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/137 "2022-12-15T04:49:57Z")
Vejo que você fez a mesma pergunta aqui: [Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - #537](https://meta.discourse.org/t/setup-discourseconnect-official-single-sign-on-for-discourse-sso/13045/537?u=simon). Se você está tentando configurar a configuração `enable discourse connect` e não a configuração `enable discourse connect provider`, o outro tópico é o lugar correto para fazer sua pergunta.
A configuração `enable discourse connect provider` é para quando você deseja usar seu site Discourse como o provedor de identidade para outro site. A configuração `enable discourse connect` é para quando você deseja fazer login de usuários no Discourse através de um site externo.
---
### Author:  [@piffy](https://meta.discourse.org/u/piffy)
#### Post date: [18 Dezembro , 2022 06:09 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/138 "2022-12-18T06:09:10Z")
Implementei o procedimento em Python para um aplicativo Flask que estou construindo. Aqui está algum código boilerplate para quem precisar. As etapas descritas neste tópico foram bem simples de seguir, mas não sou um especialista em segurança, então se eu negligenciei algo, por favor, me avise!
>
---
### Author:  [@sfoster](https://meta.discourse.org/u/sfoster)
#### Post date: [10 Maio , 2023 23:21 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/139 "2023-05-10T23:21:08Z")
Estamos tentando implementar o Discourse como um provedor de SSO e o que não entendemos é como o Discourse sabe qual usuário precisa ser verificado? As instruções dizem: “Crie uma nova carga útil com nonce e url de retorno”. Mas quando você envia isso via fetch para o Discourse, como o Discourse sabe qual usuário verificar para ver se ele está logado? Desculpe se isso parece uma pergunta estúpida, mas eu simplesmente não consigo entender como isso está funcionando e trabalhei com muitos sistemas de autenticação ao longo dos anos, então estou um tanto familiarizado. O e-mail do usuário para o qual estamos tentando verificar o status de login precisa ser incluído na carga útil enviada ao Discourse? Se sim, qual é a estrutura exata da carga útil que precisa ser enviada ao Discourse? Se não, novamente, o que o Discourse está verificando exatamente? Minha suposição é que pedimos ao usuário seu e-mail em nosso sistema e, em seguida, enviamos a carga útil com o e-mail para o Discourse para ver se aquele usuário específico está logado, mas isso não é o que as instruções dizem, então estou totalmente confuso. Obrigado por qualquer ajuda.
---
### Author:  [@sfoster](https://meta.discourse.org/u/sfoster)
#### Post date: [11 Maio , 2023 00:10 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/140 "2023-05-11T00:10:48Z")
Não se preocupe. Nós resolvemos isso. Pensamos que o URL do SSO precisava ser enviado como uma requisição POST para a instância do Discourse e então receber uma resposta. Agora vemos que isso é um redirecionamento para o Discourse, e então o Discourse redireciona de volta para o nosso site. Então, agora está claro o que fazer. Desculpe pelo post anterior.
---
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [28 Setembro , 2023 05:19 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/141 "2023-09-28T05:19:38Z")
FYI/FWIW: Enviei um PR para permitir um parâmetro `prompt=none` na solicitação de autenticação. Semelhante a um recurso no protocolo OpenID Connect, isso permite que um consumidor SSO verifique se um usuário/cliente já está logado, sem enviá-los para uma caixa de diálogo de login caso não estejam.
O PR está aguardando uma revisão final por alguém da equipe do Discourse há cerca de 8 semanas; parece um tempo bastante longo do que eu esperaria. 😿
>
>
> 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.)
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [28 Setembro , 2023 11:54 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/145 "2023-09-28T11:54:08Z")
Olá @mdoggydog - desculpe pela demora!
Acabei de revisar e mesclar o PR - obrigado pela contribuição! 🙌
---
### Author:  [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [28 Setembro , 2023 16:31 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/147 "2023-09-28T16:31:42Z")
Yay! Obrigado, @david.
Conforme prometido, acabei de atualizar o artigo da wiki aqui para incluir uma descrição do novo parâmetro (e do parâmetro `logout` anterior, e para corrigir alguns pequenos erros de digitação/gramática, e para adicionar uma seção de referências documentando a carga útil `sso=` como eu a entendo após ter pesquisado no código-fonte).
---
### Author:  [@alehandrof](https://meta.discourse.org/u/alehandrof)
#### Post date: [7 Dezembro , 2023 16:32 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/148 "2023-12-07T16:32:24Z")
Quero parar de usar nosso site como SSO para Discourse e, em vez disso, usar as ferramentas de login integradas do Discourse para limitar o acesso a certos materiais em nosso site.
Acho que a ferramenta certa a usar é: [GitHub - discourse/discourse-auth-proxy: An http proxy that uses the DiscourseConnect protocol to authenticate users](https://github.com/discourse/discourse-auth-proxy)
Não encontrei instruções extensas sobre como usá-lo.
**Posso instalá-lo na mesma droplet DigitalOcean do nosso site Discourse ou preciso hospedá-lo em outro lugar?**
Editar: negrito na minha pergunta 🙂
---
### Author:  [@alehandrof](https://meta.discourse.org/u/alehandrof)
#### Post date: [18 Dezembro , 2023 17:11 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/149 "2023-12-18T17:11:54Z")
Alguma ajuda com a pergunta acima? [Use Discourse as an identity provider (SSO, DiscourseConnect) - #148 by alehandrof](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/148?u=alehandrof)
---
### Author:  [@uckelman](https://meta.discourse.org/u/uckelman)
#### Post date: [17 Fevereiro , 2024 11:36 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/150 "2024-02-17T11:36:59Z")
Estou definindo `return_sso_url` como uma URL que, por si só, tem um parâmetro de consulta:
```plaintext
http://localhost:7000/completeLogin?returnto=%2F
```
O payload que envio para `/session/sso_provider` como parâmetro `sso` se parece com isto antes da codificação base64:
```plaintext
nonce=ENIwf0bElViDu325dTd6&return_sso_url=http://localhost:7000/completeLogin?returnto=%2F
```
A URL para a qual o Discourse realmente redireciona após a autenticação é esta (com os parâmetros `sso` e `sig` abreviados):
```plaintext
http://localhost:7000/completeLogin?returnto=/\u0026sso=...\u0026sig=...
```
O que me surpreende aqui é que a string de consulta que defini para `return_sso_url` parece ter sido decodificada por URL por _algo_, porque tem `returnto=/` em vez de `returnto=%2F`. O valor de `return_sso_url` que encontro dentro de `sso` após decodificá-lo de base64 também tem uma barra em vez de `%2F`.
É isso que eu deveria esperar que acontecesse? (Se sim, por quê?) Isso é um bug no Discourse?
---
### Author:  [@uckelman](https://meta.discourse.org/u/uckelman)
#### Post date: [17 Fevereiro , 2024 18:05 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/151 "2024-02-17T18:05:47Z")
Qual é o motivo para a carga útil `sso` conter `avatar_url` em vez de `avatar_template`, como é retornado em `/u/{username}.json` e `/session/current.json`?
`avatar_url` não está presente para usuários que não definiram um avatar, enquanto `avatar_template` contém o caminho `leter_avatar_proxy` realmente usado no Discourse para exibir avatares para esses usuários, e `avatar_url` aponta para a imagem bruta do avatar em vez de uma dimensionada para o tamanho desejado para usuários que definiram um avatar.
Parece-me que `avatar_template` é o que qualquer pessoa que pretenda usar as informações de avatar contidas em `sso` desejará — mas que precisará fazer uma solicitação de API adicional para obtê-lo.
---
### Author:  [@perryflynn](https://meta.discourse.org/u/perryflynn)
#### Post date: [24 Setembro , 2024 18:41 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/152 "2024-09-24T18:41:09Z")
No momento, estou implementando SSO no meu aplicativo, o login funciona muito bem até agora, o logout não.\n\nMinha Instância Discourse está redirecionando corretamente de volta para a URL de retorno sem nenhum parâmetro sso ou sig, mas quando abro o Discourse, minha conta ainda está logada.\n\n
\n\nAlguma ideia?
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [24 Setembro , 2024 19:39 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/153 "2024-09-24T19:39:01Z")
> [@perryflynn](#):
>
> Minha Instância do Discourse está redirecionando corretamente para a URL de retorno sem nenhum parâmetro sso ou sig, mas quando abro o Discourse, minha Conta ainda está logada.
Estou assumindo que você está usando a configuração do site `logout redirect` do Discourse para redirecionar os usuários de volta para seu aplicativo após o logout do Discourse.
Uma causa possível para o problema seria se a configuração `login required` estiver habilitada em seu site Discourse. Quando essa configuração está habilitada, o Discourse redirecionará automaticamente usuários não autenticados para o site do provedor SSO se eles tiverem acessado diretamente o site do Discourse. Isso significa que, a menos que você esteja deslogando os usuários de seu aplicativo quando eles são redirecionados pela primeira vez para a URL `logout redirect`, eles serão automaticamente logados no Discourse na próxima vez que visitarem o site. Você pode confirmar esse comportamento passando pelo processo com o inspetor do seu navegador aberto na aba de rede.
Caso seja útil, veja como o plugin [WP Discourse](https://github.com/discourse/wp-discourse) lida com o redirecionamento de logout do Discourse: [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#L232-L251).
[Previous page](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974.md?page=6)
[Next page](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974.md?page=8)