I’ve just setup a Discourse instance and added the discourse-openid-connect to it, connecting Keycloak as the OIDC provider.
After following the 3 conditions stated here with a recent update, I get the behaviour to authenticate via Keycloak, or if already logged in, clicking the “Login” button will prompt me to “Create New Account” with the fields filled in sourced from Keycloak info on the user.
Is there a way to skip this part requiring an additional step from the user? These are fields are naturally already populated from Keycloak, so there shouldn’t be a need for the user to modify them specifically for Discourse.
The account creation should be handled implicitly, similar to how Grafana is able to do it? I am aiming for each service provided by the community to support this seamless experience, that the original community account that is signed-up is all they have to deal with.
This might not make sense if you’re thinking about external auth such as Google / Facebook / Github / etc. A user can register their community account via Keycloak with one of those, but Keycloak itself which is only used internally is what is intended to work with all the individual services, so implicit/automated consent and sign-up is desirable.
New to discourse, i’ve got my SSO OAUTH2 provider setup and working. New users are seeing the prompt the first time they arrive and authenticate to discourse. How can I streamline this process and have the user automatically created. The values populated in that screen are correct, and a one time thing. What can I do to eliminate that screen and streamline the account creation process for my community users?
This is not currently possible. When users first create an account, they will need to click the “Create New Account” button on the signup form.
The behaviour that you are looking for is similar to how Discourse’s implementation of SSO works. In that case, accounts are created in the background without the user filling in the signup form. It seems it should be possible to implement similar functionality for OAuth2 logins, but possibly there are cases where not enough information is passed from the OAuth2 provider to create an account.
I haven’t put much time into this since my post here, but I did end up getting Discourse SSO feature instead to use a bridging service I came across for OpenID-Connect, it was a python service that had a docker container, that made deploying with my docker-compose setup easier.
So Keycloak provided the account already registered and signed-in, visiting Discourse would then sign-up the user with details provided from the bridge iirc. It’s been a while since I dealt with it, but this was a slightly better process than Discourse OAuth/OpenID-Connect support afaik(at least at the time, haven’t checked if anything has been done to improve it).
Either way, you don’t get account details sync’d as expected. The user needs to sign out of Discourse and back in for any sync to occur, and even then I think there were some things that could not be sync’d from the SSO provider to Discourse(groups/roles, something like that iirc had some gotchas).
You would need to detect the user details being updated from the provider to trigger updating Discourse via it’s APIs I think to get a proper sync setup. Otherwise you can have duplicated details that aren’t in sync, or confusing sync to the users.
So uhh, if the OAuth2 SSO integration you currently have is not the Discourse SSO feature that generally requires an SSO bridge afaik, but that plugin alternative, changing to the non-plugin version with an SSO bridge should get that desired experience you want iirc…
I am also interrested to avoid this “Create New Account” windows when using OAuth2.
Maybe an option can be added somewhere to skip it if all fields are available?
I just added some new site settings which will help with this. To skip the ‘create new account’ screen, enable sso_overrides_username, sso_overrides_email and sso_overrides_name.
Then to skip the popup completely, enable external_auth_skip_create_confirm
If you don’t see that option, make sure you’re on the latest version of tests-passed.
Does your OpenID connect provider verify users emails? We can only ‘trust’ the email from OIDC if it has been verified, and the verified boolean is set correctly.
@david we have 2.5.2 stable - this option is absent… Can this option be migrated to the stable branch? We need it, but we don’t use anything in production except the stable branch…
I’m afraid not, we don’t backport new features to the stable branch. Keep an eye on releases for info on when the next stable version will be released.
