So I am trying the following:
Client logs into my app via Auth0 authentication.
On successful authentication, an Auth0 rule kicks in and makes a callback to a page in my app which has a hidden iframe. This hidden iframe simply does a login to disclosure, so when the client clicks on the forum link he will already be logged in.
I am encountering a problem with the payload that is being sent to the disclosure sso URL.
The “nonce” is invalid/timed out.
Since the login is not being initiated via disclosure, I am generating a nonce in my Auth0 rule and sending that back as part of the payload to the disclosure sso URL.
Im unclear on how the nonce works so would appreciate some assistance. Is there a way to disable the nonce check in disclosure? if not, what do I need to do to get this to work?
I imagine disclosure is rejecting the sso login attempt because the nonce it received is one that it did not send in the first place.
The nonce has to be generated by Discourse. This is important for security.
Without the nonce, the SSO payload would in effect be a “golden ticket” that could always be used to sign in that user, even if he changed his password, his account in the SSO source got disabled, …
The nonce ensures that the SSO payload is a fresh response to the authentication request made by Discourse.
If you want the user to be signed into Discourse automatically, there are two easy ways:
Have Discourse be login required. Then, although the login will technically only happen once the user tries to access Discourse, the SSO process can be fully transparent to the user.
Embed an iframe that points to Discourse to start the SSO process (I think the right URL is /session/sso, but I’m not sure). Discourse will then generate the nonce and redirect to your app, which has to recognize the user by a cookie and redirect back with the corresponding SSO payload to close the deal.
thanks very much for your reply.
I have just come across the following article and not sure if this is supposed to solve this same issue? Does this make any sense to you?
Synchronize state from website to Discourse.
Login
When a user is logged in on the website, the URL that link to the forum site should be set to fourm.example.com/session/sso . Then when a user click this URL to visit forum, he will be logged in to Discourse automatically.
If your site allows anonymous browsing, make sure you detect the user login state and only append the /session/sso part for logged in user. For anonymouse user just direct them to forum.example.com/
Without this setup, when a user navigates to Discourse, he will need to click the Discourse login button to login.
Yes, that’s another approach (also easy, I simply forgot ). Just as with my version , technically, the login will only happen once the user clicks the link to Discourse, but that shouldn’t be a problem. If the user opens Discourse directly, for example through a bookmark, he will have to trigger login manually, but the rest of the process should then be fully automatic.
With this approach, too, you will have to recognize the user by a cookie once Discourse sends him with a token to your application.
thanks.
Though you say easy, Im still failing to bring the pieces together, so would like to bother you once again.
When a user is logged in on the website, the URL that link to the forum site should be set to fourm.example.com/session/sso . Then when a user click this URL to visit forum, he will be logged in to Discourse automatically.
With the current config setup as suggested, the sso_url points to Auth0 and invoking /session/sso brings up the Auth0 login box each time, even for a logged in user?
Also, cant work out what params need to be sent to /session/sso URL?
You don’t handle logins into your application yourself, you use Auth0 for that.
You want Discourse to do SSO against your application, not against Auth0 directly.
If that’s the case, Auth0 doesn’t have anything to do with Discourse specifically. (If you want Discourse to authenticate against Auth0 directly, there are some topics on that, but I personally have no idea how that works.)
None
The flow is:
You send the user to Discourse’s /session/sso URL, no parameters required.
Discourse sends the user back to you, carrying the nonce.
You sign the request and send the user to Discourse, submitting your signed ticket.
Yes, my app authenticates against Auth0 and I do not want discourse to directly go to Auth0 anymore.
Discourse, as you mentioned, should do SSO against my app.
Having said this, am I right in my understanding that the discourse SSO_URL config now simply needs to point back to my application instead of Auth0.
The only relationship that should now exist between Discourse and Auth0 is this: When the user tries to log in to Discourse and Discourse sends the user to your application, but the user is not signed into your application, then you’ll most likely want to send the user off to Auth0 so he can sign into your application first, before you send him back to Discourse. (From Discourse’s perspective, the only difference between this scenario and a “normal” SSO sign-in is that it takes a bit longer until the user returns.)
that could always be used to sign in that user, even if he changed his password, his account in the SSO source got disabled, …
). Just as with my version 
, technically, the login will only happen once the user clicks the link to Discourse, but that shouldn’t be a problem. If the user opens Discourse directly, for example through a bookmark, he will have to trigger login manually, but the rest of the process should then be fully automatic.
thanks.