The cookie key to extract the token from. e.g given a request header
Cookie: a=eyJh...;b=session;c=etc, setting the value a here will
extract the a cookie.
The header to extract the token from. If the value of the header is prefixed with
.*Bearer\, this will be ignored and only the following bytes decoded as a JWT.
e.g Authorization: Bearer eyJh....
The redirect URL to use when the JWT is expired, or absent. JWT expiry complies
with RFC7519 exp claim behaviour. JWTs rejected due to nbf (not before) claim
invalidity are also subject to this redirect, they may be understood as "expired" in
that they not valid yet. Invalid tokens are handled separately in redirectInvalid.
For either case of redirect, you may specify returnUrlParamName to indicate how
the URL redirecting the client should be forwarded; this can be used to send a client to the
login page and allow a seamless return.
The redirect URL to use when the JWT is invalid; invalidity is defined as having a bad
signature, or not meeting any specific claim matching criteria which may be specified.
Expired/absent tokens are handled separately in redirectExpiredAbsent. For
either case of redirect, you may specify returnUrlParamName to indicate
how the URL redirecting the client should be forwarded; this can be used to send a client
to the login page and allow a seamless return.
When redirecting to those URLs, then a query/search parameter will be added to the redirect URL with the original URL, for example to allow the login sub system to return the user to the page which triggered the redirect to login
The secret, this should either be an armoued (PEM encoded including header and fooder)
public key for the asymmetric algorithms, or a simple secret string for the
symmetric algorithms. Symmetric algorithms (HM..) use the same secret for signing
and verification which is insecure if the client code (e.g a single-page-app) has the secret
embedded in the bundle.
Use a symmetric algorightm (see JwtAlgo for more
information) to use a public and private key to independently verify (public key) and
sign (private key) the tokens. The ES... family produces the smallest asymmetric
signatures, if overhead introduced by using JWTs is a concern.
If using an asymmetric algorithm the value provided must be the public key provided in RFC7468 PEM format, such as:
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe
kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U
Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp
-----END PUBLIC KEY-----Generated using TypeDoc
Options for the verifyJwt method.
headerandcookieare mutually exclusive. Do not attempt to specify both, one will take precedence non-deterministically. Consider the ffollowing example:new Router({}).match( '/protected', ({verifyJwt}) => { verifyJwt({ algo: 'HS256', secret: 'supersecret', cookie: 'next-auth.session-token', redirectExpiredAbsent: '/expired', redirectInvalid: '/invalid', returnUrlParamName: 'origUrl', }) } )On requests to
/protectedthis will check for the presense of a symetrically signed (HM256, shared secret) HWT in theCookie: next-auth.session-token=eyJh...;part of the cookie, redirecting expired to/expired?origUrl=%2Fprotectedand invalid JWTs to/expired?origUrl=%2Finvalid(SeeredirectExpiredAbsentandredirectInvalidfor an explanation of the difference).If neither
redirectExpiredAbsentnorredirectInvalidare specified, then the value ofreturnUrlParamNameis ignored, and all requests are answered with an403 Forbidden.