SSO provider log in doesn't return to consumer site when authenticating with Google


(Ian Mackinnon) #1

When using Discourse as a single sign on provider, returning to the consumer site still doesn’t seem to be working under some conditions. I’ve outlined these below step by step with the unexpected behaviour indicated by distressed emoji.

With the “login required” option unchecked:

  • currently logged out of SSO consumer and Discourse
  • click to log in via Discourse
    • redirect to Discourse
    • log in overlay automatically pops up
    • click to log in via Google
      • redirect to Google
      • authenticated by Google
      • return to Discourse
    • logged into Discourse
    • doesn’t return to consumer :confused:
  • manual navigation to consumer :frowning:
  • not logged into consumer :anguished:

Also a slight annoyance when “login required” is checked. I think this could be quite confusing to some users.

  • currently logged out of SSO consumer and Discourse
  • click to log in via Discourse
    • redirect to Discourse (not yet logged in)
    • log in overlay does not pop up :neutral_face:
    • user must click “log in” again before they can enter credentials :grimacing:

For reference, this is related to some previous bug reports and a fix. These fixed redirection to the consumer site for authentication by Discourse itself, but not for authentication via Google.

https://meta.discourse.org/t/discourse-sso-provider-expect-redirect-to-sso-consumer-site/34038?source_topic_id=40923

(Jeff Atwood) #2

Wait what? If you are authenticating with Google that is not really SSO provided by Discourse, that is logging in with Google.


(Ian Mackinnon) #3

What I’m trying to achieve is:

  • Users only have to log in/out once for both www.example.com and discourse.example.com.
  • Sync usernames between both sites
  • Users may authenticate with a Google account.

Using the SSO provider feature of Discourse and “chaining” the authentication seemed like it would be a good way of achieving this this, but the behaviour described above means they must log in to each site separately. Is there some other way of setting up two sites like that?


(Tom Newsom) #4

Bump - we were about to rush into SSO for the same purpose (syncing between two userbases) but realised that the “chain” of authentication can only have one link in it.

We have separate hosting for:

members.domain.com - this is our home-made system for collecting payments and assigning access/security permissions for our real-world organisation.

discourse.domain.com - our discourse instance

We want to propagate permissions from our system to Discourse Group membership so that eg. all keyholders for our physical premises can be @mentioned.

Note that neither userbase is a subset of the other. Not all our real-world members have discourse accounts, and we have lots of discourse accounts who are not real-world members (but may be so in the future). Some real-world members use different email addresses in either system.


(Robert) #5

I have a very recent Discourse, but in my testing environment, I experience the same issue. Can someone confirm that the bug is stil around?

Edit:

Redirect to SSO consumer works if user is already logged in. It does not work, if the user signs up with Google or log in with Google.

/cc @codinghorror


(Robert) #6

@ianmackinnon, how have you worked around it? I think about a two-step procedure:

  1. one button for authentication that opens in a new tab
  2. if the redirect doesn’t work, people go back to original tab and click again on a 2nd authenticate button that does actually the same routine, but then, the user is already logged in and redirect should work.

(Robert) #7

@Tom_Newsom, @codinghorror, any news on this issue?


(Tom Newsom) #8

We rolled our own authentication process so that our domain.com site asks for your discourse username (and it guesses it based on email address, which is correct 90% of the time), then sends you a PM via the API with an activation link in it.


(Robert) #9

As far as I know, there is an API call to get the account for a given mail
address and I know that you can query for the mail address for a given
account.

Anyhow, this requires more work on my back-end. I guess I will just ask people
to click twice the registering button. The second time, the login-session is
already open and the authenticated forward back to my site is working.

I hope that at some point this will just work as expected as it is a bit
counter-intuitive to have to login twice. :frowning:


(Tom Newsom) #10

Yep, this is what we use. But some people are obstinate and use different email addresses for each side so we have to account for it.


(Thomas Hauchecorne) #11

This issue still hasn’t been fixed when using Google and alikes to log in.

This renders Discourse as an SSO provider pretty much useless in my use-case.

Any advice? @techAPJ @codinghorror