Bug 41671

Summary: OAuth2 authorization code grant for REST API
Product: Koha Reporter: David Cook <dcook>
Component: REST APIAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: new feature    
Priority: P5 - low CC: jonathan.druart, martin.renvoize, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20402
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25795
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description David Cook 2026-01-21 02:47:58 UTC
At the moment, we only allow app-to-app access via HTTP Basic Auth or OAuth2 client credentials. This gives third-party apps access to a lot of functionality and data across all users. This has data privacy/security implications.

Ideally, it would be great if third-party apps could require users to integrate with Koha using an OAuth2 authorization code grant, so that the third-party app could get access tokens scoped to the individual user which authenticates against Koha (and not via the third-party app). 

The scopes applied to to the token could be limited and the user could give consent for those scopes. 

And most of all... the third-party app would only be able to use that token for that user. This limits what the third-party app can do and what it can see.
Comment 1 David Cook 2026-01-21 02:58:08 UTC
At least initially, this grant would probably only be applicable to the /public API endpoints, which would also make it much easier to implement.

They wouldn't need any staff permissions, because all this API user would be doing are actions that a public user can do. 

--

The only time that the HTTP Basic Auth or OAUth2 client credentials grant make sense is when the resources being accessed don't include users, or when the other system using the APIs is fully trusted. 

But a lot of third-party apps aren't fully trusted, so we do need a more secure way of providing API access while keeping it scoped to a user who has explicitly authenticated at the very least.
Comment 2 David Cook 2026-01-21 03:03:07 UTC
Alternatively, if we didn't want to set up our own OAuth2 server for this grant, we could look at bug 25796 where we try to use a different server like Keycloak for the authentication part. It would take a bit of work to setup for the authorization part though. 

And I think it would still need to be limited to /public endpoints. At least initially.
Comment 3 David Cook 2026-01-21 03:04:02 UTC
I don't have any funding or plans to work on this currently, but... I think it's a direction that we really need to look at, because the current API options just aren't good enough. They're too permissive and give third-parties way too much access to personal/private information and power to mess with the system.