JSON Web Token (JWT) is a JSON-based open standard (RFC 7519) for passing claims between parties in web application environment. The tokens are designed to be compact, URL-safe and usable especially in web browser single sign-on (SSO) context. JWT claims can be typically used to pass identity of authenticated users between an identity provider and a service provider, or any other type of claims as required by business processes. The tokens can also be authenticated and encrypted. JWT relies on other JSON-based standards: JWS (JSON Web Signature) RFC 7515 and JWE (JSON Web Encryption) RFC 7516.
What is JSON Web Tokens? 
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS). IETF JWT is a security standard, that has gained a lot of support in recent times. It is currently in the final stages of becoming an official IETF standard.
The basic idea is that a user will provide a username / password combination to our auth server. The auth server will try and find the user and if the credentials are good will issue a token that the user will send to access resources on servers protected by JWT Authentication.
Hang on couldn’t I just Base64 decode the token and alter the claims? Yes you could but the signature would then not be valid. The signature is generated using a private key to hash the Header and Claims. This way only the original token will match the signature. Phew!
IMPORTANT: This raises an important implementation detail. Only applications that have a private key, ie server-side apps, can trust the claims of the token. It is not advised you put your private key in a browser side application ;).
IMPORTANT: Protecting your user’s password: You need HTTPS! Before going in to any discussion of OAuth2 and JWT implementation it is worth taking a moment to point out both these solutions require SSL (https) security. This encrypts the data that is sent along the wire, ie from the browser to the server. This is crucial because neither solutions provide a way of keeping you user’s supplied credentials secret when in transit. This means anyone snooping on an individuals wifi connection could steel their username and password, when they send it during the initial login!
A la documentació:
HI ha un middleware:
'web' => [ // Other middleware... \Laravel\Passport\Http\Middleware\CreateFreshApiToken::class, ],