Bug 41671 - OAuth2 authorization code grant for REST API
Summary: OAuth2 authorization code grant for REST API
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: Main
Hardware: All All
: P5 - low new feature
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-21 02:47 UTC by David Cook
Modified: 2026-01-21 03:04 UTC (History)
3 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.