API Access Token Does Not Respect External Auth #4461

New issue

Open

opened 2026-02-20 16:17:47 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-20 16:17:47 -05:00

Owner

Originally created by @SIN3R6Y on GitHub (Dec 9, 2020).

Issue

When using external authentication such as LDAP, a user using said external provider cannot generate an access token via the API. This comes down to this section of code in Api/V8/OAuth2/Repository/UserRepository.php

 public function getUserEntityByUserCredentials(
        $username,
        $password,
        $grantType,
        ClientEntityInterface $clientEntity
    ) {
        /** @var \User $user */
        $user = $this->beanManager->newBeanSafe('Users');
        $user->retrieve_by_string_fields(
            ['user_name' => $username]
        );

        if ($user->id === null) {
            throw new \InvalidArgumentException('No user found with this username: ' . $username);
        }

        if (!\User::checkPassword($password, $user->user_hash)) {
            throw new \InvalidArgumentException('The password is invalid: ' . $password);
        }

        return new UserEntity($user->id);
    }

Here we are simply checking if the password is valid, not actually authenticating, so users with external auth such as LDAP cannot pass this check, as they have no local password.

Expected Behavior

Users with external auth should be able to generate an access token

Actual Behavior

The password check does not account for external auth, denying the user from getting an access token

Possible Fix

I see three options,

Actually attempt to authenticate the user on token generation, granted this may be slow, and complicated
When authenticating via the UI, set the users password in database to match the provided password if external auth succeeds. Granted if the user changes their external password, the would need to log into the main UI for the API password check to update.
Allow admins to set an API Key variable per user, use this as an alternative to a users password for the API only.

Steps to Reproduce

Pretty simple, just use ldap and try to generate an access token in the api for the ldap user.

Context

We use ldap as a central authentication mechanism, and are working on integrations to use CRM data in other applications. However, with ldap users, you essentially can't use the API at all.

Your Environment

SuiteCRM Version used: 7.11.18
Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Firefox 82.0.2
Environment name and version (e.g. MySQL, PHP 7): MariaDB 10, PHP 7.4
Operating System and version (e.g Ubuntu 16.04): CentOS 8.3

Originally created by @SIN3R6Y on GitHub (Dec 9, 2020).    #### Issue When using external authentication such as LDAP, a user using said external provider cannot generate an access token via the API. This comes down to this section of code in Api/V8/OAuth2/Repository/UserRepository.php ```php public function getUserEntityByUserCredentials( $username, $password, $grantType, ClientEntityInterface $clientEntity ) { /** @var \User $user */ $user = $this->beanManager->newBeanSafe('Users'); $user->retrieve_by_string_fields( ['user_name' => $username] ); if ($user->id === null) { throw new \InvalidArgumentException('No user found with this username: ' . $username); } if (!\User::checkPassword($password, $user->user_hash)) { throw new \InvalidArgumentException('The password is invalid: ' . $password); } return new UserEntity($user->id); } ``` Here we are simply checking if the password is valid, not actually authenticating, so users with external auth such as LDAP cannot pass this check, as they have no local password. #### Expected Behavior Users with external auth should be able to generate an access token #### Actual Behavior The password check does not account for external auth, denying the user from getting an access token #### Possible Fix I see three options, 1. Actually attempt to authenticate the user on token generation, granted this may be slow, and complicated 2. When authenticating via the UI, set the users password in database to match the provided password if external auth succeeds. Granted if the user changes their external password, the would need to log into the main UI for the API password check to update. 3. Allow admins to set an API Key variable per user, use this as an alternative to a users password for the API only. #### Steps to Reproduce Pretty simple, just use ldap and try to generate an access token in the api for the ldap user. #### Context We use ldap as a central authentication mechanism, and are working on integrations to use CRM data in other applications. However, with ldap users, you essentially can't use the API at all. #### Your Environment  * SuiteCRM Version used: 7.11.18 * Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Firefox 82.0.2 * Environment name and version (e.g. MySQL, PHP 7): MariaDB 10, PHP 7.4 * Operating System and version (e.g Ubuntu 16.04): CentOS 8.3

deekerman added the

Type: Bug

Priority:Important

Area: API

labels

2026-02-20 16:17:47 -05:00

deekerman commented

2026-02-20 16:17:48 -05:00

Author

Owner

@SIN3R6Y commented on GitHub (Dec 29, 2020):

We're likely going to attempt resolve this ourselves, and contribute the changes. It looks to us like proposed options 2 and 3 are most ideal? Is it possible to get any consensus on preference here?

@SIN3R6Y commented on GitHub (Dec 29, 2020): We're likely going to attempt resolve this ourselves, and contribute the changes. It looks to us like proposed options 2 and 3 are most ideal? Is it possible to get any consensus on preference here?

deekerman commented

2026-02-20 16:17:48 -05:00

Author

Owner

@MrMontesa commented on GitHub (Oct 25, 2021):

We're currently running into the same issue. LDAP users cannot use the API so that we have to duplicate an LDAP user to a local user to make it work.
I have to admit that we're on an even older version (7.11.6) and still on API v4_1.

@MrMontesa commented on GitHub (Oct 25, 2021): We're currently running into the same issue. LDAP users cannot use the API so that we have to duplicate an LDAP user to a local user to make it work. I have to admit that we're on an even older version (7.11.6) and still on API v4_1.