Discourse: Using discourse as single sign on provider

Single sign in would be nice

I have started to examine discourse as sso provider and will try to describe my experience here.

usefull information

current status

I wrote a coffee script to try login on discourse.
Currently i am struggling with CSFR issues.

Wondering, if the discourse log view shows full request headers or only a subset.
If it shows all request headers, I have to find out, in which stage headers are dropped.

If not, I have to find an other way to debug this …

As part of the developments for the next degrowth conference, and also in collaboration with other organisations, we are preparing a common auth and SSO model. I think it’s important to keep this in sync as we discuss SSO also within Discourse - although I don’t fully understand if you’re talking simply of SSO (being able to login on one place and stay logged on others), or if you mean also Discourse as Auth provider.

You can see some of the discussions and developments we have been doing regarding auth and SSO here and there is also a whitepaper by Public Voice resulting from the Budapest exchange

A discussion more focused on TransforMap (and CHEST) was started here.

That said, I find that Discourse, now with the proper support for Groups and its very easy entrance point for new users (invitation based or self-subscription on topics), is also an interesting alternative to explore as an auth provider (if the functionality for being an OpenID provider is existing at all or easy to implement).

Lets try to keep the different efforts in sync, maybe also combine them, so that we can (help to) build something that serves a larger community and stays?

Before working on broader solutions it would be good to have this discourse running (and beeing used by our services) as OAuth provider.

In my opinion we are aiming towards authorization, not authentitication.
See also

This might be helpful too

Yes, but from my research, I would actually try to avoid OAuth (1). OpenID in fact deals with authentication (and that’s what we also aim at with the stories mentioned above). But OpenID Connect (not OpenID, which is something completely different and no longer a recommended standard and the one mentioned on your thread) on top of OAuth2, providing both for authentication and authorization.

Also if you read one of the answers:

“This is not really true any more. OAuth2 can be used for authentication and authorisation. Google
APIs use OAuth 2.0 for authentication and authorization. You can also
choose to use Google’s authentication system as a way to outsource user
authentication for your application. The only downside I can see
over OpenID [again, not OpenID Connect!] is that you have to implement it on a per-site basis. On the
plus side though, it integrates with Android properly”

I would still leave to consideration to just merge/join efforts with the current stories of providing an OAuth2+OpenID connect provider for authorization and authentication. If Discourse is not supporting this out-of-the-box, I would see it as a bad choice to invest a lot of energy there. We need solid implementations for these services and there are different softwares implementing this solidly (see research by @almereyda on the degrowth story, as well as mine and @rasos on Drupal).