Thank you. I’ll try and write here if it helped.
Thank you, your fix has helped.
1 Like
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!
1 Like
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!
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).
1 Like
I support linking by email @eviltrout since email is already such a strong identity key in Discourse.
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.
https://github.com/discourse/discourse-oauth2-basic/commit/2b9869ef2ee1c7ecf6e394c5f5e17fb085259834
3 Likes
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!
4 Likes
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?
Hi Mark,
We include it in the Business plan too! It’s not available in Standard though.
2 Likes
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?
Did you check /logs in your browser for the Discourse instances?
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.
@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?
thanks.
Hi @Mark_Zegarelli,
Apologies for the delay in response. Please PM me the logs and I will look into it ASAP.
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: http://tools.ietf.org/html/rfc6749#section-3.3). 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. 
1 Like
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.
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.
I’ve configured this to talk to an internal Keycloak instance but in order for it to work I had to uncheck the following under Settings->Login:
Enable local username and password login based accounts. (Note: this must be enabled for invites to work)
It wasn’t obvious to me, maybe this will help someone.
@eviltrout, + 1 For OIDC support