Keycloak in itself is a pain to manage as well. Without Terraform, you're lost... and integrating stuff with Keycloak is a pain as well. I've tried and failed to integrate a self-hosted GitLab instance, for example - their docs [1] don't specify anything how the Keycloak config is supposed to look like, the next best Google hit doesn't either [2], and somewhen in the last two years the third Google hit [3] got outdated - the Keycloak OIDC configuration UI got completely reorganized and renamed. Other stuff like Atlassian is a pain to integrate with Keycloak OIDC as well.
So, if anyone could point me to a working configuration for modern Keycloak and GitLab, I'd be really thankful. And if doc writers could specify a working Terraform, Ansible or whatever code that specifies the Keycloak configuration the application understands, I'd be even more thankful. OIDC is a horrible mess, I get it, but if your users can't get it to work because you specify nowhere what exact flavor and quirks of OIDC your application need, it reflects badly not just on Keycloak but on your application as well.
/rant
[1] https://docs.gitlab.com/ee/administration/auth/oidc.html#con...
[2] https://github.com/ChathuminaVimukthi/Gitlab-SSO-implementat...
[3] https://dheeruthedeployer.medium.com/gitlab-integration-with...
Given that your keycloak instance is running (and accessible to the user browser) at https://mykeycloak.net, its version is 17 or higher and you are using the realm named _master_.
Given that your gitlab is at https://gitlab.example.com.
At keycloak:
1 - create a new client, name it `gitlab` and set https://gitlab.example.com/users/auth/openid_connect/callbac... as the root url (henceforth CALLBACK_URI)
At keycloak, in the `gitlab` client settings screen, tab settings:
1 - Set `acess type` to `confidential`.
2 - Set `Direct Access Grants Enabled` to off.
3 - Set `Valid Redirect URIs` to `https://gitlab.example.com/users/auth/openid_connect/callbac...`* (that is the CALLBACK_URI followed by a *)
4 - Save it (A previously hidden credentials appear in the settings screen.)
At keycloak, in the `gitlab` client settings screen, tab credentials:
1 - note down your client secret (something like HMPhR89hoxrcotAz9vWjEAlPCWRAx2MP), henceforth CLIENT_SECRET
At your gitlab instance config file, setting gitlab_rails['omniauth_providers']:
1 - Set the content as in [1]
2 - Set args.issuer to https://mykeycloak.net/realms/master
3 - Set args.issuer.client_options.identifier to `gitlab`
4 - Set args.issuer.client_options.secret to CLIENT_SECRET
Hope that helps. If that works for you, please write a public markdown github gist with this tutorial and the title "how to configure gitlab with keycloak?" this will help future google searchers. Be sure to reinclude the question "how to configure gitlab with keycloak?" as a title inside the gist, with the tutorial following, as google favors question and answer style.
[1] = https://docs.gitlab.com/ee/administration/auth/oidc.html#con...
I haven't looked at the linked solutions specifically, but I've only rarely found this to be the case for generic protocols like this (especially anything around OAuth or OpenID). The open source solutions I've tried and given up on using always pull in hundreds of dependencies that have their own idiosyncracies as well as make a lot of undocumented assumptions and not be very well documented. Not to mention I still have to write code to use the "pre-built" solutions - usually more code than I would have had to write to just code the thing myself from scratch. They may be "better" from some perspective, but when I was working with OAuth, I tried (and tried and tried and tried) to use a pre-built solution for weeks until I finally gave up and just wrote my own in less than a day. Definitely longer and more painful to try to adopt somebody else's solution.
You can use either one of them separately or together. There is also no special glue to...glue them together, so you can use Hydra with different user management or Kratos with different OIDC server - my company at one point used Kratos for all user management, but Hydra was overkill, so we made our own OIDC server.
OIDC is basically an admission that supporting any arbitrary provider had failed, and you need to actually test with each specific implementation before marking it as being supported.
[1] https://openid.net/specs/openid-connect-discovery-1_0.html [2] https://openid.net/specs/openid-connect-registration-1_0.htm...
As much as I love the ability to use my own server it is going to fall flat for the vast majority of users if you can't support at least one of Google/Facebook/Twitter/Microsoft.
OpenID was supported by Google, Yahoo, MySpace, Wordpress and a few other big names. Not ideal but enough that you could basically expect most users to be covered.
OIDC is the biggest monopoly play in the industry right now and it’s an absolute privacy nightmare. Almost nobody seems to even notice.
Of course history has shown that people will trade literally everything for convenience so it will probably succeed. In the future if you get your Google account locked you won’t be able to access your bank account or buy a plane ticket and Google will know everything you use at all times and be able to log into anything you use. But it’ll be convenient.
Microsoft was the main proponent and gave talks to every single government agency in the world in favour of it. never mentioning OIDC. while google was promoting it left and right to developers. also never mentioning OIDC. Only the open/decentralized parts.
it was the classical embrace, Extend, Extinguish play. By now a classical move of both Microsoft and Google.
Is there anything today that I can run (self-host) for a similar result?
if you log in with your github credentials and elon musk buy github and ban all the red heads, you just lost your accounts on azure, ping, octa, etc.
The main issue is that B2B supports it pretty well, but if you need to say, do something like add an extra attribute dynamically to the JWT tokens, or allow automatic migration from a legacy IdP on first logon, you are forced to use B2C and Custom Policies which are effectively a programming language defined in XML and which are quite nasty to use. In addition to that, B2C doesn’t fully implement all of OIDC so things like client credential flow are still in “Preview” at the moment. Deployment of custom policies is also only by use of a “Preview” API too. It didn’t feel mature enough to me.
Unless I force the access token to be refreshed 20 or 30 minutes before the stated expiry time then the session gets killed off.
It works now, but there was a lot of head scratching and trail-and-error before I found out what was going on.
I am so fking looking forward to the death of this of fking grbage forum. I at some low point signed up to this forum. And I learned mostly nothing. And I am stilled annoyed cause it have a major impact at companies.
ChatGPT beats 99.9% of HN users at everything when it comes to known facts, ChatGPT can easily tell, explain, and debunk this kind of fraud/ad content. The post is mainly incorrect.
sry for hijacking yr comment
Hellō manages the social logins so I don't have to worry about adding a bunch of them (and update when new ones come out).
It's also run as a cooperative, so I appreciate the business model behind it.
With GDPR there's a compelling business case for a service provider that acts as a clearing house for personally-identifiable data, so that, as a business, one would only ever deal with anonymized data, thus effectively outsourcing GDPR compliance.
