Btw, I also have thoughts on how to use Keycloak to provide SSO for the Koha REST API as well: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796. In theory, it would allow SSO authenticated users to use the REST API from other SSO authenticated apps outside of Koha. I work on a large project which has a lot of different services (from multiple different vendors) and they all use Keycloak for SSO and a Kong API Gateway does a number of checks on the JWT that the services pass around. The services still have to do their own token checks too, but it’s a really slick way of handling authentication across a wide number of services using a central identity provider. It also means you wouldn’t have to give a 3rd party a staff-level Koha API user. They’d be able to leverage the user’s SSO session to access APIs that the user is authorized for at the Koha level. (That would mean adding more “public” API endpoints but I think that’s a good thing.) Discovery layers would also be able to make great use of this. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: dcook@prosentient.com.au <dcook@prosentient.com.au> Sent: Monday, 25 July 2022 11:27 AM To: 'Tomas Cohen Arazi' <tomascohen@gmail.com>; 'Martin Renvoize' <martin.renvoize@ptfs-europe.com> Cc: 'Koha Devel' <koha-devel@lists.koha-community.org> Subject: RE: [Koha-devel] QA for Bug 30988 - Add generic OpenIDConnect client implementation Hi Tomas, I thought that you were working on an OpenID Connect implementation, but then I started to doubt my memory. I suppose the takeaway is that I should never doubt myself haha. Yeah Bug 30988 is basically a copy of Bug 10988 (the Google version). I have never liked Bug 10988, but it’s hard to argue with something in production, and I’m tired of maintaining my own local OpenID Connect implementation these last 8 years. Of course, there are times where I think about writing a Koha plugin to do it instead. Locally, I’ve implemented it as a sort of built-in plugin using these hooks https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24539. Those hooks could always be changed to support the Koha Plugin system though. Anyway, please CC me into your implementation when you submit it. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Tomas Cohen Arazi <tomascohen@gmail.com <mailto:tomascohen@gmail.com> > Sent: Sunday, 24 July 2022 4:47 AM To: David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > Cc: Koha Devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] QA for Bug 30988 - Add generic OpenIDConnect client implementation Hi, David. I meant to answer your first email. I'm submitting (immediately) an alternative implementation I've been working on but failed to wrap up sooner. I've read the one you pointed and if fairly similar to the google oaidc implementation for OPAC, so it is correct. My plan is to do it for staff as well, using libraries. El vie, 22 jul 2022 7:03, <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió: Hi all, Just wondering if anyone has time to QA “Bug 30988 - Add generic OpenIDConnect client implementation”. It would be great to get this additional authentication option into Koha as it would really round out Koha’s AuthN offerings. I could do some testing for bugs of the QAer’s choice if that helps. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/