I've got just a couple of comments after a cursory look...

In tests, pieces of code are often repeated, is there a generally accepted method of reusing them?

Depending on what those pieces are, put them into a library (say, TestLib.pm in the t/ directory). Then:

use warnings;
use strict;

use lib 't/';

use TestLib;

use Test::More;

...
[download]

It becomes a pain in the rear to have to modify several tests in several files if you change the code tests are testing.

The documentation appears to be very thorough. Good job. I've passed up on what look like half decent Dancer2 plugins due to lack of documentation.

Also kudos on using Email::Valid instead of regex for email validation. Realistically, to use regex to thoroughly validate an email address, you'd be dealing with a regex straight from the depths of hell.

About the code (I took a glance, I didn't go through it thoroughly)... I personally like to see use strict; and use warnings; at the top of every Perl file, script or library. Also, it's best practice to assign all parameters from the @_ array at the top of a function/method. For example, instead of:

sub _register_hooks {
    my $self = shift;
 
    $self->app->add_hook(
        Dancer2::Core::Hook->new(
            name => 'before_template_render',
            code => sub {
                my $tokens = shift;
    ...
[download]

I'd have:

sub _register_hooks {
    my ($self, $token) = @_;
 
    ...
[download]

This way, anybody reading your code understands exactly how many and which parameters the sub wants and/or needs. To further, if you ever change the parameters coming in, you don't have to go searching for their order by trying to seek out shift statements half way through the sub. Doing it by shifting so far into the sub can lead to head scratching as to why you're getting 'baz' as a parameter for $token instead of token data, because you shifted off a new parameter that wasn't aligned properly.

Using my ($x, $x, %z) = @_; is essentially self-documenting code, on the first line of the sub definition.

For small things like this:

sub BUILD {
    shift->_register_hooks;
    return;
}
[download]

I prefer to write it like:

sub BUILD {
    $_[0]->_register_hooks;
}
[download]

Again, just a preference, but it leaves @_ intact, and in a method, $_[0] unambiguously refers to the object (or class, as it were).

Same as below. If my sub grows to three or more lines, or has more than two parameters, I replace the $_[0] etc with the way I showed above.

sub _validator_language {
    shift->config_validator->language(shift);
    return;
}
[download]

...

sub _validator_language {
    $_[0]->config_validator->language($_[1]);
}
[download]

...is there a reason you're intentionally returning undef?

As far as private methods, because I don't often document them (because they're usually very small and specific), I do usually add a small comment before assigning parameters just so it's easy for others to see what it's to be doing.

sub _access_token_data {
    # Fetches and stores the access token data to the AUTH_CACHE_FILE
 
    my ($self, $data) = @_;
 
    ...
}
sub _access_token_set_expiry {
    # Sets the access token expiry date/time after generation and
    # renewal
 
    my ($self, $token_data) = @_;
}
[download]