Wouldn't this change mean that the user now would have to enter their api token when using the login form? That doesn't look right to me. And inside the authenticator we do not use the user provider at all so for that to make it work this change is not necessary if I do not miss anything.

Well, there is no login form ;-) This is about the API token. What I'm trying to fix is that at https://symfony.com/doc/current/security/guard_authentication.html#step-3-configure-the-authenticator there are some parts missing (commented out) of security.yaml, and I'm just telling people what's expected to be in there.

And inside the authenticator we do not use the user provider at all

Token authentication works without a user provider? Well, if that's really the case (and you certainly know that better than I do) this PR is obviously obsolete. (Usually I try things out before, but I can't remember the details).

So in this case there should be a note that people can delete their user provider (which they still will have, if they are coming from https://symfony.com/doc/current/security.html#guard-authenticators )

Token authentication works without a user provider? Well, if that's really the case (and you certainly know that better than I do) this PR is obviously obsolete. (Usually I try things out before, but I can't remember the details).

The authenticator will get the user provider passed to its getUser() method. But in our concrete example the method is implemented like this:

public function getUser($credentials, UserProviderInterface $userProvider)
    {
        if (null === $credentials) {
            // The token header was empty, authentication fails with HTTP Status
            // Code 401 "Unauthorized"
            return null;
        }

        // if a User is returned, checkCredentials() is called
        return $this->em->getRepository(User::class)
            ->findOneBy(['apiToken' => $credentials])
        ;
    }

I think this approach was used as we do not load the user by username (which we actually do not know) here.

So maybe it would be better to have an authentication method that does not only use a token, but also an identifier.

So maybe it would be better to have an authentication method that does not only use a token, but also an identifier.

No, I think that's OK; not having an identifier is the reason for having a token, after all.

I'll just drop in a short note somewhere à la "If you're doing it this way, you don't need a user provider".

OK?

Hmm, this is exactly one of the pain points of guards that will be fixed in the experimental authenticator system. As the user provider argument is not nullable, you must have a user provider, even though you don't use it at all (so it can be a completely empty InMemoryUserProvider).

As it's so ugly, it's probably best to "hide" it a bit in the docs. So I'm in favor of not adding more examples/text, but instead modify the configuration example in "Step 3) Configure the Authenticator". If we replace the first # ... comment with your user provider config, I think it should be clear enough that you must configure some sort of user provider. Please note that the article describes in "Step 1" that one must first follow the main guide, so most should have some sort of user provider set up already (as they also already have a working user entity).

(also note that with this config, you can use $userProvider->loadUserByUsername($apiToken), as you've configured apiToken to be the username, but I think it'll be too confusing if we would use this)

but instead modify the configuration example in "Step 3) Configure the Authenticator". If we replace the first # ... comment with your user provider config

Yes, good idea!

you can use $userProvider->loadUserByUsername($apiToken)

You mean inside getUser(), instead of ->findOneBy(['apiToken' => $credentials])? Well, why not? If we need to set some user provider anyway, why not set the "right" one right away? I don't think that's confusing. Which is the cleaner/better way?

Sorry for failing to react on your questions in this issue @ThomasLandauer.

Well, why not? If we need to set some user provider anyway, why not set the "right" one right away? I don't think that's confusing. Which is the cleaner/better way?

Yes, alright. But let's add a small comment that explains that "username" is the property configured by property (thus apiKey).

Do you want to update this PR, or shall I create a new one based on your changes?

I hope I got what you mean :-)

Thank you @ThomasLandauer!