Omniauth jwt redirect

Product Support SSO

AI-generated summary

In a discussion about SSO with JWT using the discourse-omniauth-jwt library, arivanandan describes a flow where users log into their own site, receive a JWT, and are automatically signed into Discourse — but end up留在 Discourse instead of returning to their original site. Despite exploring redirection methods like the origin param and destination_url cookie, nothing worked. eviltrout clarifies that this flow isn’t standard: users should typically start on Discourse, be redirected to the external site for auth, then return to Discourse. Logging in directly on the external site doesn’t serve much purpose unless the embed can use the auth session — which, as arivanandan later realizes, it actually can: the session cookie allows embeds to show/hide private topics. As a workaround, arivanandan plans to open Discourse login in a new tab, letting users access private topics after a refresh.

1

After this, I’ve been able to get SSO up and running with JWT.

With the discourse-omniauth-jwt library, I’m not sure how to redirect people after sign-in.

When a user logs into my site, I obtain the JWT and sign them into discourse as well immediately. At the end of this flow, they end up at the discourse site instead of back at my site.

I have tried checking out the omniauth library’s redirection methods which includes the origin param and the destination_url cookie from here. None of them seem to work.

Maybe @eviltrout can shed some light on this.

EDIT: Just realized I’ve been looking at two different libraries, omniauth and discourse’s omniauth callbacks. Anyway, still unsure how to make this work.

2

So the issue here is:

  1. a user logs into your site
  2. you redirect them to discourse to log in there
  3. they end up logged in at discourse?

I don’t think this is a supported path. In general, a user would be on discourse, click login, visit your site for auth and be redirected back. If a user logs in directly on your site, they should stay on your site.

Typically how we do this is keep Discourse logged out, but when they click “Login” it’ll redirect back without having to fill out the authentication form again.

3

Hmm right makes sense. Logging in doesn’t do much now that I think about it since the embed can’t make use of the auth session.

4

So, the embeds do make use of the auth session (or the session cookie) to show or hide private discourse topics.

This auth flow does make sense, but for starters, I’m going to redirect people to the discourse forum for login on a new tab. They will be able to access private topics after a refresh.