[Bug 41671] New: OAuth2 authorization code grant for REST API
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 Bug ID: 41671 Summary: OAuth2 authorization code grant for REST API Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: REST API Assignee: koha-bugs@lists.koha-community.org Reporter: dcook@prosentient.com.au QA Contact: testopia@bugs.koha-community.org CC: tomascohen@gmail.com 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20402 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25796, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25795 CC| |jonathan.druart@gmail.com, | |martin.renvoize@openfifth.c | |o.uk -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- I've been thinking more about this lately, and I suppose this would work best with third-party (discovery) systems (like Aspen/VuFind) where people are using their own devices to do logons. For public devices like kiosks... it can be more complicated. If they have a keyboard, then it's OK, but there are scenarios where you might not have a keyboard. You might just be scanning your barcode. I suppose that's where we run into either the Device Authorization grant or Token Exchange. -- I'm hoping to wrap up the XOAUTH2 work soon and then probably switch to this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |dcook@prosentient.com.au |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- While I haven't used Device Authorization grants, I have used Token Exchange in a few contexts. It has complexities but it can be very UX-friendly. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- I think really what we're trying to do here is have Koha be a proper OAuth2 authorization server. And we get part of the way with Koha/REST/V1/OAuth.pm but we don't fully implement it. I am tempted to transition the syspref "RESTOAuth2ClientCredentials" to something like "RESTOAuth2Server", but I suppose we could just add new ones like "RESTOAuth2AuthCode" and "RESTOAuth2DeviceGrant". And then with bug 25796... maybe we have something like "RESTOAuth2AuthServer" where the options are "Koha Auth Server", "External Auth Server". -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41671 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42942 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org