JSON Web Token e Laravel – Parte 2 – Installazione e Configurazione del Pacakge

Nella parte precedente di questo articolo abbiamo analizzato più da vicino il meccanismo dei JSON Web Tokens. Come funzionano, a cosa servono e dove possono esserci utili.

Per implementare l’autenticazione JWT nella tua applicazione puoi seguire varie strade: nulla ti vieta infatti di gestire da te tutto il meccanismo, ma è bene sapere anche che esistono dei package che cercano di svolgere al meglio il lavoro al posto tuo.

Uno di questi è jwt-auth di Sean Tymon. Nelle prossime righe ti spiegherò come installarlo e configurarlo correttamente. Nella prossima parte, invece, vedremo come usarlo tramite alcuni esempi pratici.

Installazione

La procedura di installazione, come puoi ben immaginare, non differisce molto da quella di altri package.

Si parte con l’inclusione della dipendenza nel file composer.json del tuo progetto.

“require”: {
“tymon/jwt-auth”: “0.5.*”
}

Nota: la versione 0.5.* è quella prevista per Laravel 5.X. Se stai usando Laravel 4.X allora devi scegliere tra la versione 0.3.* o 0.4.*.

A questo punto avvia il comando

composer update

per installare il package e le sue dipendenze.

Terminata la procedura, apri il file config/app.php ed aggiungi ai tuoi service provider

‘TymonJWTAuthProvidersJWTAuthServiceProvider’

ed all’array delle facade aggiungi l’elemento

‘JWTAuth’ => ‘TymonJWTAuthFacadesJWTAuth’

… ed è fatta! Opzionalmente, puoi aggiungere anche la facade

‘JWTFactory’ => ‘TymonJWTAuthFacadesJWTFactory’

che ti fornisce un maggiore controllo sulla costruzione del payload del tuo token.

Il passo immediatamente successivo è il pubblicare il file di configurazione, tramite il comando

php artisan vendor:publish –provider=”TymonJWTAuthProvidersJWTAuthServiceProvider”

Infine, per concludere, provvedi a generare un secret da usare per i tuoi token usando il comando

php artisan jwt:generate

Configurazione

Analizziamo al volo il file di configurazione pubblicato precedentemente, durante l’installazione. Ho eliminato i commenti per ovvie ragioni di spazio.

env(‘JWT_SECRET’, ‘changeme’),

‘ttl’ => env(‘JWT_TTL’, 60),

‘refresh_ttl’ => env(‘JWT_REFRESH_TTL’, 20160),

‘algo’ => env(‘JWT_ALGO’, ‘HS256’),

‘required_claims’ => [‘iss’, ‘iat’, ‘exp’, ‘nbf’, ‘sub’, ‘jti’],

‘blacklist_enabled’ => env(‘JWT_BLACKLIST_ENABLED’, true),

‘blacklist_grace_period’ => env(‘JWT_BLACKLIST_GRACE_PERIOD’, 0),

‘providers’ => [

‘jwt’ => ‘TymonJWTAuthProvidersJWTNamshi’,

‘auth’ => ‘TymonJWTAuthProvidersAuthIlluminate’,

‘storage’ => ‘TymonJWTAuthProvidersStorageIlluminate’

]

];

Cosa abbiamo qui? Analizziamo le opzioni più importanti:

• secret: la secret key che verrà usata per criptare i tuoi token;
• ttl: il “time to live”, ovvero la durata della vita di un token in minuti;
• refresh_ttl: il tempo che ha l’utente per effettuare il refresh del token, nel caso in cui sia scaduto. Di default è impostato a due settimane, il che vuol dire che l’utente avrà due settimane di tempo dal login per aggiornare un token scaduto. Nel caso in cui l’utente non entrerà nell’applicazione per due settimane, allora dovrà necessariamente effettuare il login di nuovo;
• algo: l’algoritmo usato per l’hash. Lascialo così com’è senza problemi;
• required_claims: è possibile specificare quali claim devono necessariamente essere inseriti nel payload del token. In caso contrario verrà sollevata un’eccezione;
• blacklist_enabled: se tale opzione viene impostata su false, i token non vengono più invalidati. Possono essere aggiornati ma quelli precedenti rimangono validi. Di default il suo valore è true;
• providers: in questo array vengono indicate le varie implementazioni da usare per quanto riguarda il sistema di autenticazione e di storage. Nel caso in cui volessi usarne di diversi allora è qui che devi cambiare i valori con quelli corretti;

Dopo questa breve panoramica e la preparazione necessaria, direi che ci siamo. Adesso puoi “girare pagina” e buttarti nella terza ed ultima parte di questa mini serie.