How do I store JWT and send them with every request using react - express

So happy right know because I got my basic registration/authentication system going on.
so basically I got this :
app.post('/login', function(req,res) {
Users.findOne({
email: req.body.email
}, function(err, user) {
if(err) throw err;
if(!user) {
res.send({success: false, message: 'Authentication Failed, User not found.'});
} else {
//Check passwords
checkingPassword(req.body.password, user.password, function(err, isMatch) {
if(isMatch && !err) {
//Create token
var token = jwt.sign(user,db.secret, {
expiresIn: 1008000
});
res.json({success: true, jwtToken: "JWT "+token});
} else {
res.json({success: false, message: 'Authentication failed, wrong password buddy'});
}
});
}
});
});
Then I secure my /admin routes and with POSTMAN whenever I send a get request with the jwt in the header everything works perfectly.
Now here is the tricky part, basically When i'm going to login if this a sucess then redirect me to the admin page, and everytime I try to access admin/* routes I want to send to the server my jwToken but the problem is, how do I achieve that ? I'm not using redux/flux, just using react/react-router.
I don't know how the mechanic works.
Thanks guys

Do not store the token in localStorage, the token can be compromised using xss attack.
I think the best solution will be to provide both access token and refresh token to the client on login action.
save the access token in memory (e.g redux state) and the refresh token should be created on the server with httpOnly flag (and also secure flag if possible).
The access token should be set to expire every 2-3 minutes.
In order to make sure that the user will not have to enter his credentials every 2-3 minutes I have an interval which calls the /refreshToken endpoint before the current token expires (silent refresh token).
that way, the access token cannot be compromised using xss/csrf.
but using an xss attack, the attacker can make a call on your behalf to the /refreshToken endpoint, but this will not be harmful because the returned token cannot be compromised.

1- login component send a login request to the API server endpoint
2- server API endpoint returns a token
3- I save the token in user's localStorage
4- all the API calls from now on will have in the header
Example: https://github.com/joshgeller/react-redux-jwt-auth-example
Security update:
As #Dan mentioned in the comment, tokens should not be stored in Localstorage because every javascript script has access to that one, which means third party scripts you don't own could access tokens and do whatevery they want with it.
A better place is to store it as a Cookie with HttpOnly flag.

Since saving the JWT in localStorage is vulnerable to XSS attacks, the other way can be saving it inside a httpOnly cookie but too bad that you cannot do that in frontend, check this post.
The only option you have is to configure your server-side to return you a the JWT in a httpOnly cookie and also accept the token inside httpOnly cookie. You'll also have to think of how you want to deal with token expiry.
NOTE:
While modern browsers support and prevent reading/writing via httpOnly cookies, but I am not sure about old browsers.

Related

How to handle JWT refreshing on server side (Next.js or any other)

I have two cookies being stored: JWT and refresh token, both are httponly; path=/, so they are send on all requests, including the API (which doesn't use Bearer, but instead reads the JWT directly from the cookies).
The implementation is as usual, the JWT is short lived, and the refresh token is used to get a new one. The refresh token is rotating and after used is invalidated.
On the client, refreshing the token is no issue. When a 401 is returned by the API a call is made to /auth/refresh-token and the request is retried.
On the server however, (e.g. on getServerSideProps) it seems to be quite difficult to refresh the JWT. What I have attempted is to create a custom server and a middleware that checks when a JWT is expired and attempts to refresh it.
I can think of two issues with that, first is that the custom server is called on every resource, that includes all json, js, static files, etc... that Next.js serves. When two requests are made with the same tokens (I can handle this when making API calls, but Next.js also sends requests to the server and I cannot control those):
1. Two requests with expired JWT are sent to the server
2. The back-end receives the requests and on both determines it needs to refresh the token
3. Eventually one of the requests will complete, invalidating the refresh-token
4. The other request now has an invalidated refresh token and cannot get a new JWT
Second issue, what if the user doesn't receive the response, scenario:
1. A request with an expired JWT is sent
2. The back-end refreshes it and sets the new cookies
3. The back-end then has to read lots of data from a database which takes a few seconds
4. User closes the page before receiving the response
5. At this point the user has an invalidated refresh token and an expired JWT because the response with the new cookies was never received
How are these cases usually handled? It seems like it would be a common issue with rotating refresh tokens, but I couldn't find anything useful on this online.
You can follow this practice.
Save refresh token in the http-only cookie
No need to save JWT in the cookie for better security and keep it in the response of refresh token as well as login endpoint.
Save JWT expiry in a normal cookie
Call refresh token endpoint to get new JWT when expiry token is not present or getting 401 error.
In getServerSideProps also you can call the refresh token endpoint always as you don't need to persist JWT anywhere.
You may need to get the cookie from req.headers.cookie and pass it in the header when you are calling the refresh token endpoint from the server.
//inside getServerSideProps
const browserCookie = req.headers.cookie;
const refreshJWTTokenResponse: any = await refreshJWTToken(browserCookie);
//service call
export async function refreshJWTToken(refreshTokenCookie: any): Promise<{}> {
let headers = new Headers();
headers.append("Cookie",`${refreshTokenCookie}`);
const options = {
method: 'POST',
headers: headers,
credentials:'include',
};
...
}

How to verify a keycloak kcToken and kcIdToken fetched from browser's cookies after #react-keycloak/ssr login?

I am trying to secure NextJS API endpoints with keycloak. Keycloak authentication is already implemented on the front-end pages. The user is forced to sign in before they can view those pages. Two tokens are saved in the browser's cookies following keycloak authentication. They are kcToken and kcIdToken.
Those same pages call on api endpoints, which also need to be secured, in case someone is trying to access them outside of the application pages.
I am trying to use the two tokens (kcIdToken and kcToken) to secure the APIs endpoints. I am not trying to require authentication again at the api level, but directly fetch these two tokens from the browser when an api endpoint is called and verify the tokens to check authentication status, etc.
Is there a way of verifying these two tokens ? I checked the format of these two tokens and they are not exactly jwt tokens with headers, payload, etc.
I am able to get these two tokens. I am not sure though what are their differences and uses.
What are the differences and uses of kcToken and kcIdToken, obtained using the #react-keycloak/ssr authentication for keycloak ?
Here is my api endpoint function:
const handler = async (req, res) => {
// Fetching the tokens from the request cookies
const { kcToken, kcIdToken } = req.cookies
console.log(kcIdToken)
console.log(kcToken)
// If the tokens are undefined or non-existent in the browser
if ( !kcIdToken || !kcToken) {
return res.status(401).json({ success: false, message: "Unauthorized Access"})
}
// Verify kcToken and kcIdToken are valid
// Get user information, roles, etc, if the tokens are valid
return res.status(401).json({ success: false, message: "Unauthorized Access"})
}
How do I verify these two tokens validate the correct authentication state ? What are the uses and differences between these two tokens ? Are these tokens coming directly from keycloak or from #react-keycloak/ssr ?

Ktor Keycloak Acess Token Route Protection

I'm using a server that authenticates through keycloak. In keycloak I have created a realm and am able to get an Access token as a response. This access token gets fed now into my Ktor application.
However, I'm not quite sure how to protect routes in an easy manner. I want to have some protected routes that have a authenticate("keycloakOAuth"){} scope around it which handles validating the access token and refreshing using the refresh token if the access token is expired.
Currently I have keycloak inside Ktor configured as this:
authenticate("keycloakOAuth") {
get("login") {}
route("/callback") {
// This handler will be executed after making a request to a provider's token URL.
handle {
val principal = call.authentication.principal<OAuthAccessTokenResponse>()
if (principal != null) {
val response = principal as OAuthAccessTokenResponse.OAuth2
call.respondText { "Access token: ${response.accessToken}" }
} else {
call.respondText { "NO principal" }
}
}
}
}
This works fine because when I go to login I'm getting sent to the Keycloak login page and I can login. When I logged in the callback executes and I get my Access Token back.
When I'm trying to protect routes however, some odd stuff happens. I know that I need to validate the incoming JWT token. But I have no clue how to given the Ktor capabilities. The examples are also of little help, since they are quite vague.
Currently I have something like this:
authenticate("keycloakOAuth") {
get("/testAuth") {
val principal = call.authentication.principal<OAuthAccessTokenResponse.OAuth2>()
if(principal != null) {
call.respondText("Authenticated!")
} else {
call.respondText("Unauthenticated...")
}
}
}
But my application will always send me to the login page and then callback page, even though I am sending the Bearer token when I'm testing this call.
My question is:
How do I protect routes in a manner that they need a valid token, with the same syntax that Ktor uses (like authenticate(){}). Do I need to configure JWT for this?
When you request one of the routes under authenticate, the full cycle of OAuth authentication is triggered. This is because the Authentication plugin is designed so a client sends credentials and gets authenticated for each request. For some reason, OAuth integration was implemented on top of the Authentication plugin hence such unexpected behavior.
To solve your problem you can have only /login and /callback routes restricted. In the callback's handler save user ID and tokens in a session or in any other storage for future use. For other routes, you can check manually the fact that a user is authenticated and then use tokens from storage to acquire protected data from the resource server. For convenience, you can create some extension functions to minimize the amount of boilerplate code. Unfortunately, there is no built-in functionality to make it work out of the box.
You don't need to configure JWT for this.

Proper way to do jwt refresh tokens with express

I'm thinking of a proper pattern for implementing refresh tokens, but on few steps, I have some questions. I am using nextjs with axios on the frontend and express with cookie-session on the backend.
Here are steps I'm thinking of:
Client sends a log-in request. After logging in I put the access token in the session object and the refresh token into res.cookie, both secure and httpOnly.
// for simplicity options are left out
req.session = { accessToken };
res.cookie("refreshToken", refreshToken)
On every request with axios I supply just the access token. Here's where the first question arises. How would I supply only the access token, without sending the refresh token too, if both are httpOnly?
If the access token is valid do whatever is needed. If not, need to get the refresh token and compare it to a stored one, and so on. Here's the second question. While I understand I need to retrieve the refresh token in this step, how would I do it properly?
Any more advice would be great, thanks.
[EDIT] After some thought I realised that making access token not httpOnly would allow me to send just access token, which would solve my problem. But if that is incorrect please let me know.
Here is the standard pattern - as in this code of mine:
Client sends access token (which may be in an HTTP Only cookie)
When it expires they try to refresh the access token by calling a /refresh endpoint
If the refresh succeeds they retry the API request with the new access token
Otherwise the client redirects the user to sign in again
Don't make the access token non HTTP Only, since any malicious code could then grab it from document.cookie.
This also allows you to set a path of /refresh for the RT cookie, so that it is only sent on refresh requests.
Also ensure that cookies containing tokens are strongly encrypted (AES256) using a symmetric key only known server side. This Express library will do the work for you.

Using Firebase for server side authentication

I have Firebase authentication set up on the client side, and on the server side I can take a JWT token and decode the account ID. But how does this work when I want each page load to be authenticated on the server before the page is generated?
On login or each page load, can I simply store the last JWT token into cookies so that I can read them on my server? Aside from that, I don't know how else for my server to get that information aside from each link being an AJAX call.
This seems to be the only way to do it presuming you're using the firebase auth library to decode and verify the tokens on the server and not some kind of JWT parsing library.
Firebase admin includes methods for decoding and verifying id tokens and extrapolating all the information. This prevents cookie forgery and keeps firebase auth as your single source of truth for whether or not a user is authenticated.
for example (in node):
const admin = require("firebase-admin");
admin.initalizeApp({
credential: admin.credential.cert(yourServiceAccountJsonHere),
databaseURL: "http://YOURDATABASE.firebaseio.com/"
});
admin.verifyIdToken("usertokenasastring") //returns a promise
.then(function(decodedToken){
//process the decoded user token somehow
});
Firebase makes a call to your database, and makes sure that that user is logged in and that all the other information in the JWT makes sense, so you don't have to worry about implementing any kind of verification server side.