I am having trouble trying to understand the rationale for creating a new JWT for the session cookie when the JWT created is almost identical to the already issued ID token.
Referencing the Manage Session Cookie documentation, it recommends a session cookie to be created using createSessionCookie
as follows:
getAuth()
.createSessionCookie(idToken, { expiresIn })
.then(
(sessionCookie) => {
// Set cookie policy for session cookie.
const options = { maxAge: expiresIn, httpOnly: true, secure: true };
res.cookie('session', sessionCookie, options);
res.end(JSON.stringify({ status: 'success' }));
},
(error) => {
res.status(401).send('UNAUTHORIZED REQUEST!');
}
);
Why can't I just write:
// Set cookie policy for session cookie.
const options = { maxAge: expiresIn, httpOnly: true, secure: true };
res.cookie('session', idToken, options);
res.end(JSON.stringify({ status: 'success' }));
Digging deeper, I thought that perhaps the session cookie that was created by Firebase had additional attributes, or perhaps obfuscated the claims in the idToken
in some manner so that it could be more secure. But I found the claims of the idToken
and session cookie to be almost identical. The only difference is that the kid
and iss
are different...and I don't understand what's the benefit of resigning the token with another key.
From the documentation on Create custom tokens using the Firebase Admin SDK:
These tokens expire after one hour.
This is re-iterated later in the page in the table of claims for when you Create custom tokens using a third-party JWT library:
exp
— Expiration time
The time, in seconds since the UNIX epoch, at which the token expires. It can be a maximum of 3600 seconds later than theiat
.
So Firebase ID tokens are valid for at most an hour, never longer.
Compare that to the documentation on authenticating with session cookies, which says:
create session cookies with custom expiration times ranging from 5 minutes to 2 weeks.
So session cookies can be valid much longer than ID tokens, which makes them more suitable for scenarios when a longer validity is required/useful.
If you don't (know whether you) have such a scenario, I recommend sticking to using ID tokens - as those are Firebase most common authentication mechanism.