| Summary: | OAuth2 authorization code grant for REST API | ||
|---|---|---|---|
| Product: | Koha | Reporter: | David Cook <dcook> |
| Component: | REST API | Assignee: | 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 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. 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. 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. |