# 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:** 1
### Author:  [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [7 Setembro , 2015 09:19 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/1 "2015-09-07T09:19:22Z")
Então você quer usar o Discourse como provedor de identidade para sua própria aplicação web? Ótimo! Vamos começar.
## Habilitar a configuração do provedor [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true)
Em Configurações do site de administração do Discourse (/admin/site\_settings), habilite a configuração `enable discourse connect provider` e adicione uma _string_ secreta a `discourse connect provider secrets` (usada para _hash_ de _payloads_ SSO).
## Implementar o [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) em sua aplicação web:
- Gere um _nonce_ aleatório [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce). Vamos chamar esse valor de `NONCE`. Salve-o temporariamente para que você possa verificá-lo com o valor _nonce_ que será retornado na resposta.
- Crie um novo _payload_ com o `NONCE` e uma `RETURN_URL` (para onde o Discourse redirecionará o usuário após a verificação). O _payload_ deve ser assim: `nonce=NONCE&return_sso_url=RETURN_URL`. O host da `RETURN_URL` deve corresponder ao padrão de domínio que você usou ao configurar `discourse connect provider secrets`.
- Codifique em Base64 o _payload_ bruto acima. Vamos chamar esse _payload_ de `BASE64_PAYLOAD`
- Codifique em URL o `BASE64_PAYLOAD` acima. Vamos chamar esse _payload_ de `URL_ENCODED_PAYLOAD`
- Gere uma assinatura HMAC-SHA256 do `BASE64_PAYLOAD` usando seu segredo de provedor SSO como chave, depois crie uma _string_ _hex_ em minúsculas a partir disso. Vamos chamar essa assinatura de `HEX_SIGNATURE`
## Enviar solicitação de autenticação para o Discourse
Redirecione o usuário para `DISCOURSE_ROOT_URL/session/sso_provider?sso=URL_ENCODED_PAYLOAD&sig=HEX_SIGNATURE`
## Receber resposta do Discourse:
Se as etapas acima forem feitas corretamente, o Discourse redirecionará o usuário logado para a `RETURN_URL` fornecida. Você receberá parâmetros de _query string_ com `sig` e `sso` junto com algumas informações do usuário. Agora siga as etapas abaixo:
- Calcule o HMAC-SHA256 de `sso` usando o segredo do provedor SSO como sua chave.
- Converta `sig` de sua representação de _string_ _hex_ de volta para _bytes_.
- Certifique-se de que os dois valores acima sejam iguais.
- Decodifique em Base64 `sso`; você obterá a _query string_ incorporada passada. Isso terá uma chave chamada `nonce` cujo valor deve corresponder ao _nonce_ passado originalmente. Certifique-se de que este é o caso e exclua o _nonce_ do seu sistema.
- Você descobrirá que essa _query string_ também conterá um monte de informações do usuário. Use como achar melhor.
Pronto. Agora você deve ter configurado sua aplicação web para usar o Discourse como provedor SSO!
## Mais Parâmetros, Mais Opções
Além de `nonce` e `return_sso_url`, o _payload_ da solicitação tem vários parâmetros opcionais adicionais.
- `prompt`: Se `prompt=none`, então a solicitação SSO é tratada como uma solicitação de “apenas verificação”. Se o navegador/dispositivo já estiver logado no Discourse, o Discourse retornará uma resposta SSO bem-sucedida contendo informações de autenticação do usuário, como de costume. Se o navegador/dispositivo _não_ estiver logado, o Discourse não solicitará que o usuário faça login e retornará imediatamente uma resposta SSO contendo o parâmetro `failed=true` em vez de informações do usuário. Isso fornece um mecanismo para consultar se o usuário está logado, sem nunca direcionar o usuário para um diálogo de login caso não esteja.
- `logout`: Se `logout=true`, então a solicitação SSO se torna uma solicitação de _logout_. Se um usuário estiver logado no Discourse nesse navegador/dispositivo, ele será desconectado desse dispositivo. Em ambos os casos, o Discourse redirecionará imediatamente de volta para a `return_sso_url`, _sem_ `sso` ou `sig` adicionados à _query string_.
- `require_2fa`: Se `require_2fa=true`, o Discourse exigirá que o usuário verifique a autenticação de dois fatores antes de ser redirecionado de volta. A resposta do _payload_ incluirá `confirmed_2fa=true` se o usuário concluiu com sucesso a verificação 2FA, ou `no_2fa_methods=true` se o usuário não tiver métodos 2FA configurados.
`prompt=none` e `logout=true` são mutuamente exclusivos; não faz sentido fornecer ambos na mesma solicitação.
## Referência do _Payload_ `sso=`
Parâmetros de solicitação:
- `nonce`: (string, obrigatório) uma _string_ aleatória gerada de forma segura
- `return_sso_url`: (string, obrigatório) a URL para a qual redirecionar com a resposta
- `prompt`: (string, opcional) Se `none`, sonda o status de autenticação sem solicitar o login do usuário.
- `logout`: (booleano, padrão `false`) Se `true`, desconecta o usuário do Discourse.
- `require_2fa`: (booleano, padrão `false`) Se `true`, exige que o usuário verifique a autenticação de dois fatores antes de redirecionar de volta.
Parâmetros de resultado:
- _Não há payload `sso=` ou assinatura em resposta a uma solicitação de logout, apenas um redirecionamento para a `return_sso_url` simples da solicitação._
- O _payload_ de resultado para uma solicitação de login sempre conterá o `nonce`, refletido da solicitação.
- O _payload_ de resultado também refletirá quaisquer outros parâmetros de solicitação. _Não confie nesse comportamento; não é necessariamente intencional e não é um aspecto garantido da API._ (Por exemplo, por que o parâmetro `return_sso_url` é copiado para o _payload_ que é enviado para a `return_sso_url`?)
- Se a solicitação falhou ao autenticar um usuário, o _payload_ de resultado conterá `failed=true`.
- Se a solicitação conseguiu autenticar um usuário, o _payload_ de resultado conterá as credenciais/informações do usuário:
### Implementações oficiais do Discourse sobre “Usando o Discourse como provedor de identidade”:
- Um proxy http (usando golang) que usa o [Discourse SSO](https://meta.discourse.org/t/13045?silent=true) para autenticar usuários (somente administradores): [GitHub - discourse/discourse-auth-proxy: An http proxy that uses the DiscourseConnect protocol to authenticate users · GitHub](https://github.com/discourse/discourse-auth-proxy) (feito por @sam)
### Implementações de comunidade contribuídas sobre “Usando o Discourse como provedor SSO”:
- Um script PHP que implementa o Discourse como provedor SSO: [Discourse sso provider login · GitHub](https://gist.github.com/paxmanchris/e93018a3e8fbdfced039) (feito por @paxmanchris)
- Ruby:
[GitHub - AstonJ/sso\_with\_discourse: Implementation in ruby for https://meta.discourse.org/t/using-discourse-as-a-sso-provider/32974 · GitHub](https://github.com/AstonJ/sso_with_discourse)
- Erlang:
[https://github.com/reverendpaco/discourse-as-sso-erlang](https://github.com/reverendpaco/discourse-as-sso-erlang)
- Node.js:
[GitHub - edhemphill/passport-discourse: A Passport strategy for authenticating using a Discourse forum · GitHub](https://github.com/edhemphill/passport-discourse)
[GitHub - ArmedGuy/discourse\_sso\_node: npm package for Discourse SSO login features. · GitHub](https://github.com/ArmedGuy/discourse_sso_node)
- [ASP.NET](http://ASP.NET) Core (requer apenas configuração):
[GitHub - Biarity/DiscourseSso: Easy, configurable Discourse SSO: GET /auth/login -\> recieve a JWT with user data · GitHub](https://github.com/Biarity/DiscourseSso)
- Extensão MediaWiki (PHP):
[DiscourseSsoConsumer, a SSO extension for MediaWiki](https://meta.discourse.org/t/discoursessoconsumer-a-sso-extension-for-mediawiki/211445?u=mdoggydog) (feito por @mdoggydog)
---
### Author:  [@jamesmarkcook](https://meta.discourse.org/u/jamesmarkcook)
#### Post date: [12 Setembro , 2015 08:10 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/2 "2015-09-12T08:10:13Z")
Great how to, thanks.
FYI, the term ‘nonce’ has an unfortunate meaning in Britain.
---
### Author:  [@gogo52cn](https://meta.discourse.org/u/gogo52cn)
#### Post date: [9 Fevereiro , 2016 01:49 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/4 "2016-02-09T01:49:29Z")
I wrote a class to implement the process in Ruby. I use it to work with devise in my web application.
[https://github.com/gogo52cn/sso\_with\_discourse](https://github.com/gogo52cn/sso_with_discourse)
---
### Author:  [@ianmackinnon](https://meta.discourse.org/u/ianmackinnon)
#### Post date: [12 Março , 2016 01:11 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/5 "2016-03-12T01:11:28Z")
> [@techAPJ](#):
>
> Compute the HMAC-SHA256 of sso using sso\_secret as your key.
`sso` seems to have a trailing newline which needs to be included when sent to the HMAC function, so it’s important to make sure that SSO consumer applications don’t strip whitespace from these query arguments.
---
### Author:  [@geneles](https://meta.discourse.org/u/geneles)
#### Post date: [14 Abril , 2016 02:43 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/6 "2016-04-14T02:43:28Z")
Our app users get their own subdomains. Is there a way to implement this with variable SSO urls?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [14 Abril , 2016 06:32 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/7 "2016-04-14T06:32:51Z")
interesting, this is tricky you would need to monkey patch this in, or better still make core extensible in this way and add a plugin.
---
### Author:  [@reverend\_paco](https://meta.discourse.org/u/reverend_paco)
#### Post date: [3 Maio , 2016 00:10 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/8 "2016-05-03T00:10:46Z")
Hello,
I have created an Erlang implementation for encoding/decoding the payloads described in this specification. You can find it here:
[https://github.com/reverendpaco/discourse-as-sso-erlang](https://github.com/reverendpaco/discourse-as-sso-erlang)
Feedback is welcome.
Thanks to @mpalmer on another [thread](https://meta.discourse.org/t/setting-the-session-token--t-on-the-entire-domain-not-just-my-subdomain) for setting me straight.
As I put together this implementation, I realized that the specification does not say too much about a few things:
1. the user information that is returned in the query parameters,
2. what happens when a user is not found
When I got around to testing I found the answers, and then confirmed by looking at the code, here: [discourse/app/controllers/session\_controller.rb at main · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/master/app/controllers/session_controller.rb#L33)
I shall assume that in regards to 1. that while new user information may be added, that none of these values (“name”,“username”,“email”,“external\_id”, etc) will be removed. This is just as important, contractually as what is described in the main post.
One piece of feedback I’d like to give the Discourse team is that it would be nice to add a means to optionally return back to the calling application in the case of a missing user.
Currently, at [line 51](https://github.com/discourse/discourse/blob/master/app/controllers/session_controller.rb#L51) a non-logged-in or non-registered user will be forwarded to the Discourse login page. While this can be useful, I would rather programmatically have the option to learn that this person has not yet logged in (or registered) and give them the opportunity _on my site_ to continue anonymously.
I can imagine something like this:
```plaintext
DISCOURSE_ROOT_URL/session/sso_provider?
sso=URL_ENCODED_PAYLOAD&sig=HEX_SIGNATURE&
returnBackIfUserMissing=true
```
and then the Discourse site sending back to the `return_sso_url` with either a special header, or an attribute, rather than redirecting to /login.
This change should be backwards compatible.
I’m new here, so if this is something that could be contributed via a pull-request, please tell me and I could take a shot at it next week.
thanks,
daniel
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [3 Maio , 2016 00:50 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/9 "2016-05-03T00:50:46Z")
> [@reverend\_paco](#):
>
> One piece of feedback I’d like to give the Discourse team is that it would be nice to add a means to optionally return back to the calling application in the case of a missing user.
Sure, totally open to add another option to the payload you send us for `create_new=false` PR welcome.
---
### Author:  [@reverend\_paco](https://meta.discourse.org/u/reverend_paco)
#### Post date: [6 Maio , 2016 18:46 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/10 "2016-05-06T18:46:33Z")
added a PR for this
[https://github.com/discourse/discourse/pull/4211](https://github.com/discourse/discourse/pull/4211)
Commit-Message:
```plaintext
Implemented an optional 'no_user_found_return_sso_url' parameter to be called
by the client when client is using Discourse as an SSO and wants Discourse to
redirect back to a place of the client's choosng when a user is not found.
Currently, the Discourse as an SSO implementation checks the cookies _t and
_session_forum to see if the user is registered and present in the database
(_t is the token that is located in the users table). If a user is not found,
the current implemenation forwards to the forum's /login URL. This behavior
may be what the client wants, but it would be good to give an option to the
client to send somewhere else.
This commit allows the client to embed an optional 'no_user_found_return_sso_url'
parameter in the payload, prior to base64 and URL-encoding. If the Discoure SSO
endpoint detects that this parameter is present in the payload (and has a non-empty
value) the Discourse server will redirect to this new location if it does not detect the
user. If this parameter is not present, then the redirection to /login will take place
as it currently does.
Additionally, as the client may choose to use the same URL for
'no_user_found_return_sso_url' as for 'return_url', this commit introduces a new
query-string name-value pair to be sent back to the client 'no_user_found_return_sso_url'
location. This parameter 'user_found' will ALWAYS be sent back to the client, either when
the user is found and 'return_url' is used or when the user is not found
'no_user_found_return_sso_url' is used (values will be 'true' and 'false' respectively).
```
thanks,
daniel
---
### Author:  [@fantasticfears](https://meta.discourse.org/u/fantasticfears)
#### Post date: [6 Maio , 2016 19:29 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/11 "2016-05-06T19:29:30Z")
Nice work 🙂
`redirect_to` can be routed to a url with parameters. But isn’t a `create_new=false` enough? Or whatever name it is. You’ll get nonce and the flag back.
---
### Author:  [@reverend\_paco](https://meta.discourse.org/u/reverend_paco)
#### Post date: [6 Maio , 2016 19:48 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/12 "2016-05-06T19:48:15Z")
> [@fantasticfears](#):
>
> But isn’t a `create_new=false` enough? Or whatever name it is. You’ll get nonce and the flag back.
I wanted to give the client the flexibility of sending a failure to a different URL than the success url (return\_url). With complicated SSO architectures, this might be a requirement. (Selfishly, I wanted to make my return endpoint code less convoluted – i.e. on my side I have two codebases at /sso for success and /sso\_failure for failure).
Implicitly there are already two URLs (return\_url for success and ‘/login’ for failure) – I didn’t want to lose that.
So just to be clear, the payload you send to the Discourse endpoint should have _both_ `return_url` and `no_user_found_return_sso_url` if you want Discourse to send it back when no user is found. It should have `return_url` only if you are ok with Discourse forwarding to /login.
Should look like this:
1.If you want Discourse to forward to login if no user found, then:
`PAYLOAD = return_url=mydomain.com/clientendpoint&nonce=xE787euK`
2. If you want Discourse to send back to you to the same endpoint for failure as success:
`PAYLOAD = no_user_found_return_sso_url=mydomain.com/clientendpoint&return_url=mydomain.com/clientendpoint&nonce=xE787euK`
3. If you want Discourse to send back to you to a **different** endpoint as success:
`PAYLOAD = no_user_found_return_sso_url=sub.mydomain.com/handleNewUser&return_url=mydomain.com/clientendpoint&nonce=xE787euK`
Potentially a bit over-engineered, but that was my thought process.
---
### Author:  [@fantasticfears](https://meta.discourse.org/u/fantasticfears)
#### Post date: [6 Maio , 2016 20:24 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/13 "2016-05-06T20:24:05Z")
> [@reverend\_paco](#):
>
> I wanted to give the client the flexibility of sending a failure to a different URL than the success url (return\_url). With complicated SSO architectures, this might be a requirement. (Selfishly, I wanted to make my return endpoint code less convoluted – i.e. on my side I have two codebases at /sso for success and /sso\_failure for failure).
To be clear, it’s not user\_not\_found, it’s not logged in.
It’s about protocol not engineering in the first place. Given two endpoints, you have to deal with two possible endpoints. In both cases you **must** validate the nonce and destroy it. It’s a hurdle not benefit.
In extreme case, a client can ask Discourse several times with/without session (current\_user), thus you would get n responses in each endpoints. It would be twice as hard to secure it due to changing cookies on your end.
---
### Author:  [@reverend\_paco](https://meta.discourse.org/u/reverend_paco)
#### Post date: [6 Maio , 2016 21:55 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/14 "2016-05-06T21:55:36Z")
> [@fantasticfears](#):
>
> It’s about protocol not engineering in the first place.
Completely agree on protocol over engineering. Hence, my submission.
The semantics are equivalent to an if-else block, or more generally a case/switch block. result\_url is our true condition, and user\_not\_found\_url is our else block. If we didn’t provide it, we would _force_ the client to have to deal with the ‘failure’ condition in the same codebase/endpoint – and for 90% of the people, this will be fine.
90% of people who want Discourse to return back to them will set `return_ur`l and `user_not_found_url` to be exact same thing. This bears repeating, and really renders the motivations for the 10% moot.
90% of the time you will make `return_url` and `user_not_found_url` the exact same thing. These 90%-ers will use their JSESSIONID/ PHPSESSID/ ASPSESSIONID /\_session to look up the returned encoded nonce in their framework-supplied session-store and engineer accordingly.
7% of people will be happy to pass it to a different URL on their same app-server, which does some decoration (servlet-chains anyone?) or routing, but still looks up the nonce in their session.
3% will have some complicated polyglotish system that uses a distributed session store (like memcache) to store sessions for different app servers implemented in different legacy codebases. It’s up to them to store/invalidate the nonce across these different systems.
I realize I might not have been completely clear, but the `user_not_found_url` still receives the `sso` and `sig` parameters, just like the `return_url`.
So, if you are the 90% scenario, when you get the payload and verify/decode it, you will find the parameter `user_found`= **false** | **true** to know why it’s coming back to you.
---
### Author:  [@reverend\_paco](https://meta.discourse.org/u/reverend_paco)
#### Post date: [7 Maio , 2016 14:20 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/15 "2016-05-07T14:20:46Z")
@fantasticfears, as per your recommendation on the PR, I have renamed the attribute from `user_not_found_url` to `return_sso_unlogged_in_url`.
---
### Author:  [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [8 Maio , 2016 10:53 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/16 "2016-05-08T10:53:15Z")
3 posts were split to a new topic: [Can Discourse be used as an OAuth provider?](https://meta.discourse.org/t/can-discourse-be-used-as-an-oauth-provider/43872)
---
### Author:  [@thomasschmit](https://meta.discourse.org/u/thomasschmit)
#### Post date: [11 Maio , 2016 17:39 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/17 "2016-05-11T17:39:55Z")
Great job !
Do you know how it possible to adapt it to GitLab in order to allow the Discourse users to directly login there?
---
### Author:  [@edhemphill](https://meta.discourse.org/u/edhemphill)
#### Post date: [11 Julho , 2016 05:56 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/18 "2016-07-11T05:56:02Z")
Hey folks, I could not find anything, so I created a npm for Discourse auth using Passport for node.js.
It’s here, and in npm if anyone needs it:
[https://github.com/edhemphill/passport-discourse](https://github.com/edhemphill/passport-discourse)
(really appreciate the team’s work, we’ve been a user since the very early days @ [talk.wigwag.com](http://talk.wigwag.com))
---
### Author:  [@reverend\_paco](https://meta.discourse.org/u/reverend_paco)
#### Post date: [10 Outubro , 2016 11:04 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/19 "2016-10-10T11:04:12Z")
@sam,
I have submitted a reply back to your rejection of the PR:
[Optional 'no\_user\_found\_return\_sso\_url' parameter for using Discourse as SSO by reverendpaco · Pull Request #4211 · discourse/discourse · GitHub](https://github.com/discourse/discourse/pull/4211)
As I have been relying on my patched version of discourse for these months, I would be interested in convincing you as to my need.
---
### Author:  [@reverend\_paco](https://meta.discourse.org/u/reverend_paco)
#### Post date: [17 Outubro , 2016 12:58 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/20 "2016-10-17T12:58:48Z")
> [@reverend\_paco](#):
>
> @sam,
>
> I have submitted a reply back to your rejection of the PR:
> [Optional 'no\_user\_found\_return\_sso\_url' parameter for using Discourse as SSO by reverendpaco · Pull Request #4211 · discourse/discourse · GitHub](https://github.com/discourse/discourse/pull/4211)
>
> As I have been relying on my patched version of discourse for these months, I would be interested in convincing you as to my need.
If this PR is going to be rejected, could you explain what I can do to get the functionality that I need?
---
### Author:  [@Sveinn\_S](https://meta.discourse.org/u/Sveinn_S)
#### Post date: [28 Novembro , 2016 11:26 UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/21 "2016-11-28T11:26:36Z")
Does anyone know of a wordpress plugin that works with discourse as the SSO provider?
[Next page](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974.md?page=2)