OAuth2 Basic Support


(Robin Ward) #24

Okay I think I’ve fixed it here, can you try the latest version of the plugin?


(It’s hard for me to test as I don’t have a provider which needs that header)

(Maxim Mazin) #25

Thank you. I’ll try and write here if it helped.

(Maxim Mazin) #26

Thank you, your fix has helped.

(Mikhail Vink) #27

As the OAuth2 support works great for our custom provider now (I’m working with @mazine, thanks for help, @eviltrout !), it seems that the plugin is missing the part related to “connecting” to the existing account via the email we’re getting from Auth Provider (it’s not possible to connect the account by external id only). Right now it authorises on the external provider and redirects to the signup with the info filled out and tells me my username and email has already been taken (as I already have my admin account there, and that’d be a case for ~400 imported users too I guess).

I’ve looked at the similar problem which’s been solved for Discourse Omniauth Gitlab plugin some time ago and tried to apply the same approach on the forked OAuth2 Basic Support plugin, but it seems I’m missing something in the parameters or checks as the patched plugin doesn’t actually change behaviour of the login form (still pre-filled without connection by email). Probably I’m missing something out in the system arrays/parameters naming.

Could you please have a look if I’m missing smth? Thanks a lot!

(Robin Ward) #28

Why is it not possible to connect by the id? By default the plugin will use the id retrieved from the JSON feed as a key to retrieve that user the next time they log in.

If the users were already created before you added the plugin, if you have their ids you can create the records in the database so that they can log in. But they definitely need a unique id to identify them!

(Mikhail Vink) #29

There are unique IDs returned by the external auth provider, and they’re indeed used for re-login of our users. The problem we have is related to already created accounts before we activate the plugin (in fact, those are bulk imported accounts). Imported accounts lack external auth provider ID and these IDs are not easily retrievable from the database we’re migrating from (in fact, they’re just not there - we can try to get it connecting to the auth provider via API and get IDs searching by email, but it looks like an overkill).

It looks like providing opportunity to initially “connect” user account by email (in addition to id, if it’s not possible to “connect” by unique id) would make the workflow more convenient and straightforward in such cases, especially considering that email is also unique in Discourse (but we need to set unique external_id from the auth provider in any way and use it when possible to connect). It also seems quite logical and consistent to add it here considering that e.g. official Discourse SSO us it in exactly that way (first trying to connect by external_id, then by email if no external_id is assigned with providing external_id for future logins).

(Jeff Atwood) #30

I support linking by email @eviltrout since email is already such a strong identity key in Discourse.

(Robin Ward) #31

Okay, I took a look at the code and this wasn’t hard to add. If you get the latest version of the plugin you should find that it will match a user on email if the oauth2_email_verified setting is set to true.


(Mikhail Vink) #32

Thanks a lot @eviltrout! Works like a charm.

I’ve made a small improvement related to case-sensitivity and sent a pull request at Improvement: downcase the email when searching for an account by email by mikhailvink · Pull Request #8 · discourse/discourse-oauth2-basic · GitHub - please have a look. It seems that according to this topic and some others, an email has been made a non-case-sensitive entity in Discourse. The added “find by email” feature uses “User.where(email: result.email).first” which seems to be case-sensitive (so it doesn’t find the email if it’s arriving capitalised from the OAuth provider which might be the case). So I’ve added downcase there, otherwise we can probably replace it with find_by_email (which is downcased by default) instead of User.where. Thank you!

(Mark Zegarelli) #33

Hey Guys.

Is this plugin available on one of your non-enterprise hosting plans? I need it for an install, but the enterprise plan is way more than I’ll need for everything else. Could I use it on a business plan?

(Robin Ward) #34

Hi Mark,

We include it in the Business plan too! It’s not available in Standard though.

(Mark Zegarelli) #35

Thanks @eviltrout

We were able to get this configured this morning, but we’re getting an error when we try to log in.

Where is this authorization supposed to take place? We checked logs on our OAuth provider, saw that the request from our Discourse instance was processed successfully.

Any thoughts?

(Jeff Atwood) #36

Did you check /logs in your browser for the Discourse instances?

(Mark Zegarelli) #37

Hi Jeff. Nothing appearing in the Discourse logs either.

I tested our OAuth provider with a Discourse instance we’re hosting, and that worked as it should.

(Jeff Atwood) #38

Perhaps @techapj can help you take a deeper look?

(Mark Zegarelli) #39

@codinghorror Would it be better for me to take this to the Support category? Also, I’ve got some logs I’d like to share that might help troubleshoot this, but I don’t want to post them publicly. Can I send those to someone?


(Arpit Jalan) #40

Hi @Mark_Zegarelli,

Apologies for the delay in response. Please PM me the logs and I will look into it ASAP.

(SnipersCode) #41

Hey guys. Just wanted to let you know I love the custom oauth2 support.

It would be great if we could request scopes from the authorization endpoint (space delimited: RFC 6749 - The OAuth 2.0 Authorization Framework). I’ve forked the repo and added a hard-coded value for now

Also, is there a way to disable users from changing their email? If I globally disable changing the email, I get a forbidden request from the api endpoint, which is expected. On my website, I already keep track of their email and they are able to change it from there. What would be ideal is to prevent users from changing their email on discourse and be able to send an api command to discourse to change their email from my site.

I looked into using the sync_sso enpoint, but it seems to be only for the normal sso and the external id given to the oauth2 basic plugin does not reflect the external id in the normal sso. Using the enable_sso option also breaks the site as I assume that it is only to be used with the normal sso.

Lastly, is there a way to change the avatar with the oauth2 basic plugin like with the normal sso?

Again, ideally, it would be great if this could also use the same “overwrite [username, email, name, avatar]” for this as well.

I also wouldn’t be opposed to someone pointing me in the right direction on how to adapt this basic oauth2 support plugin so I could code it myself. :smiley:

(Logan Mathews) #42

Is anyone aware of any work being done on supporting OpenID Connect (OIDC) so that a custom userinfo endpoint isn’t needed? It would allow for other projects (such as Drupal8) and utilize discourse as the forum solution that much easier.

(Robin Ward) #43

As far as I know, nobody is currently working on it. When I implemented this plugin, none of the use cases I had for it supported OIDC.