How to create custom authenticators ?

[Sunchock]

Hi,

For my project, I need to create my own Authenticator with a custom User Provider and User entity.

I created a class into a file named App\Shield\Authenticators\MyAuthenticator for example and tried replacing "CodeIgniter\Shield\Entities\User" with my own: "App\Entities\User". However, i'm getting an error in the "login" function : it's not compatible with the prototype declaration of the AuthenticatorInterface. This is due to the class of the $user parameter.

I thought I could extend a "BaseAuthenticator" like the "BaseModel" for models, but I couldn't find anything in the Shield source code.

My question is: Is it possible to create my own authenticator, and if so, how?

Thank you in advance for your help.

[datamweb]

You can absolutely create a custom User Provider and User Entity — Shield fully supports this out of the box, and you can set them up easily by following the documentation.

Regarding a custom Authenticator: Shield already provides a solid set of built-in authentication methods, including:

    /**
     * --------------------------------------------------------------------
     * Authenticators
     * --------------------------------------------------------------------
     * The available authentication systems, listed
     * with alias and class name. These can be referenced
     * by alias in the auth helper:
     *      auth('tokens')->attempt($credentials);
     *
     * @var array<string, class-string<AuthenticatorInterface>>
     */
    public array $authenticators = [
        'tokens'  => AccessTokens::class,
        'session' => Session::class,
        'hmac'    => HmacSha256::class,
        // 'jwt'     => JWT::class,
    ];

These cover most use cases in typical applications.
Because of that, it’s not entirely clear why you would need a completely custom authenticator.

If you can explain what specific behavior or functionality you’re trying to achieve — something that the existing authenticators cannot provide — it would help a lot. There may be a simpler or more integrated solution available for what you’re trying to do.

[Sunchock]

Hi,

Thank you for taking the time to reply.

In my project, we need to connect users via an external API.

Indeed, we don't store passwords or tokens.

During login, we send the credentials to an internal HTTP API, which returns a response with the request status. If successful, we create a session for the user.

So I tried extending the session authenticator, but I encountered many difficulties because the class contains many functions and private properties that I had to reimplement, and the methods of the Authorizable trait are not easily overridden.

[datamweb]

Hi,
First of all, I apologize for the delay; I’ve unfortunately been tied up with another project.
I suggest that you implement a Custom Authenticator. I’ve prepared documentation on how to do this and submitted it as a PR #1299. If possible, please review it.

[Sunchock]

Hi @datamweb,
I took a look at the PR, thank you very much for adding it!

Unless I'm misunderstanding, I'd like to suggest modifying the session authenticator to make it a parent class that can be inherited, as that's what we want to do in our project.

Indeed, we want the ability to be authenticated externally and, when successful, create or retrieve the user's session.

[datamweb]

I thought the previous explanations were sufficient to clarify how to create a custom authenticator and properly integrate it into the authentication flow.

However, it seems that you insist on directly extending the parent class(Session) and are effectively suggesting that private methods be changed to protected to allow overriding or modifying their internal behavior in the child class?

[Sunchock]

Yes, that's exactly it.

I prefer a library to be easily extensible. If you agree, I think we could make that change.

Given the original question of this discussion, I'm approving your answer via the PR in the documentation. Thank you very much.

[datamweb]

I prefer a library to be easily extensible. If you agree, I think we could make that change.

Honestly, I’m not a big fan of doing this, but feel free to submit a PR for review.