I'm fine making it overridable by changing self to static, but I don't think it's worth exposing configuration for.
We may add some phpdoc on the constant telling about the issue regadding long passwords with session storages, and eventually mention the OWASP password storage cheatsheet for guidance.
PR welcome

For instance, with oauth2, the implementation of knpuniversity/oauth2-client-bundle which states in the documentation (here) to send your oauth2 access token directly as the user badge "identifier" :

return new SelfValidatingPassport(

new UserBadge($accessToken->getToken(), function() use ($accessToken, $client) {

[...]
Later, you're supposed to retrieve your identifier in a user provider or in the closure of user badge to construct your "user".

Now with SF6.2 and the access_token authentication method, you can directly have the real user identifier with almost no effort.
A possible AccessTokenHandler in your case could be as follows:

final class AccessTokenHandler implements AccessTokenHandlerInterface
{

    private $client;

    public function __construct(
        ClientRegistry $clientRegistry,
        private readonly EntityManagerInterface $entityManager,
    )
    {
        $this->client = $clientRegistry->getClient('facebook_main');
    }

    public function getUserBadgeFrom(#[\SensitiveParameter] string $accessToken): UserBadge
    {
        /** @var FacebookUser $facebookUser */
        $facebookUser = $this->client->fetchUserFromToken($accessToken);
        $email = $facebookUser->getEmail();

        // 1) have they logged in with Facebook before? Easy!
        $existingUser = $this->entityManager->getRepository(User::class)->findOneBy(['facebookId' => $facebookUser->getId()]);

        if ($existingUser) {
            return new UserBadge($existingUser->getIdentifier(), fn() => $existingUser);
        }

        // 2) do we have a matching user by email?
        $user = $this->entityManager->getRepository(User::class)->findOneBy(['email' => $email]);

        // 3) Maybe you just want to "register" them by creating
        // a User object
        $user->setFacebookId($facebookUser->getId());
        $this->entityManager->persist($user);
        $this->entityManager->flush();

        return new UserBadge($user->getIdentifier(), fn() => $user);
    }
}

Although the limit is indeed a bit arbitrary, I don't feel very comfortable about allowing users to override the length limit.

In the new security system, a lot more functionality can rely on the user identifier and unintentionally create a new risk for CVE-2016-4423. For instance, the login throttling feature also uses the user identifier in both the lock and cache storage.

Also, this patch must target 6.3, where we already have much better support for token-based user providers like @Spomky shows.

So I would say I would rather challenge code that requires long user identifiers, than allowing increasing the length.

Thanks everyone for reaching out !

@chalasr :

I'm fine making it overridable by changing self to static, but I don't think it's worth exposing configuration for.

I'm good with that !

@wouterj
Would you be ok with the 'static' solution as a compromise ?
That would allow a clean way to do it code-wise.

@Spomky :
Looks interesting, thanks a lot for your detailed answer, I'll definitely take the time to try that approach !
Is that already a thing with 6.2 ? Or is it a future 6.3 feature as hinted by @wouterj answer ?

Although the limit is indeed a bit arbitrary, I don't feel very comfortable about allowing users to override the length limit.

Me neither.

I don't believe, UserBage was ever meant to hold a full JWT token payload instead of a user identifier. So everyone who did that must've known that they had implemented a dirty hack.

We should rather provide an alternative (if there isn't already one) than making that constant overridable.

Is that already a thing with 6.2

Yes, I mentioned it in #49830 (comment)
No need for any modification except the knpuniversity/oauth2-client-bundle documentation to take into account the access token feature

Let's close here, as it seems to be agreed upon that this does not need fixing on the Symfony side.

Indeed 👍