Controlling API / Webservices access

[BrainforgeUK]

Steps to reproduce the issue

Create a component providing webservice (in /api).
Create webservices plugin for that component.
Create a user for accessing that webservice component.
... to obtain a token this user has to have superuser access.

Expected result

(a) Webservice for that token / user returns required information.

(b) The token can only be used to access webservices from my component. Cannot be used to access other webservices.

(c) If that user logs into the site they only have access to my webservice component (or any other component I give them access to).

Actual result

(a) Works OK.

(b) The token can access all system webservices.

(c) As this is a superuser this user has full access to the site.
I only want them to be able to see their user details (including token) and the administration areas of my component.

System information (as much as possible)

I have a 3rd party application which does not provide webservices. My component provides webservice access to part of that component and has a dashboard so administrator can see a status summary (e.g. items in webservice queue).

Additional comments

(b) Can be overcome by adding an OnUserLogin function to the webservices plugin.
This allows me to check who the user is and the component they want to webservice access to.

(c) Requires two users 'myuser-api' to use token access and 'myuser' for normal administrator login.
Unnecessary complication with need to remember two accounts and two passwsord.
Just want one account 'myuser' who can see / reset their token and be an administrator of my component.

Have I overlooked something? Something for the future? Or a good reason for not being able to implement with a single non-superuser login?

[iamteajazz]

Hi! I'd like to contribute to this issue. A possible solution could involve introducing scoped tokens that are linked to a specific component during token creation. This would allow:

Tokens to work only for their assigned webservice.
Users to retain admin privileges for their component without being superusers.
If this aligns with the project’s direction, I’d be happy to draft a pull request.

[BrainforgeUK]

Thanks,
Below is a suggestion to achieve what I would like to see.
Combined these changes will restrict a user to only those parts of the site they are allowed access to when using either the API or login.

(a) Move the login at then end of route() to the beginning of initialiseApp() in ApiAllplication.php

$this->login(['username' => ''], ['silent' => true, 'action' => 'core.login.api']);
parent::initialiseApp($options);

This will ensure that the user only has access to the webservices they are allowed to access (existing plugin permissions).
The existing call to login() after routing would be replaced with a check on the current user.

(b) In the User Options add a Joomla API tab containing a multiple select list of User Groups.
By default only super users have access to their API Token, as existing.
In addition any user in the User Group select list can access their token on the user page.

=================================================================
There maybe some good reasons for not doing that!
I don't have the time to get into arguments about it.
If there is a consensus and someone wants to investigate and implement a pull request then go ahead.

A pull request might be something I would do, but do not have the time.
For the current project I will go the non API route with component site views / layouts returning JSON data, with the view checking whatever token mechanism I've provided them with.

[iamteajazz]

Thank you for this detailed suggestion! Your approach to moving the login() call and adding user group-based token visibility is clear and well thought out. I’ll look into implementing these changes as a pull request. If anyone has additional input or concerns about this approach, I’d be happy to discuss and iterate accordingly.

[wilsonge]

This was intentional with the auth plugin we wrote. We wanted people to use it as a method to manage content/articles etc rather than be a generic service like that linked to user session tokens. Long term we'd hoped that people in the 3rd party ecosystem would consider writing a plugin that implements a full oauth compliance server - where that would include this sorta thing. Unfortunately we thought it was likely the complexity of all the component mapping would alienate the average developer hence we went for a lighter weight approach in core.