I am trying to get my own authentication service working with my nextJS app. My own authentication service is a simple rest api that returns a JWT access token and a JWT refresh token on entering correct credentials.
Currently I am setting the JWT refresh token as a httpOnly cookie and the JWT access token into a state variable (in memory) in my nextjs app.
I am stuck at these points:
How do I pre-render sites in nextjs (getServerSideProps) with some custom user data that I want to fetch based on the JWT access token?
How can I pass this access token to getServerSideProps?
I wanted to pass the access token that is stored in memory to getServerSideProps but unfortunately I could not get it to work. Or at least I don't know how.
Do I have to put the JWT access token as a httpOnly cookie as well? Then I can retrieve the access token cookie in getServerSideProps.
But then this approach is vulnerable to CSRF as pointed out in this question:
Where to store the refresh token on the Client?
Is there a possibility to make a solution with two httpOnly cookies (one for refresh and one for access token) secure?
Is it secure to set both cookies as httpOnly and samesite strict? and set the path of the refresh token cookie to /refresh-token only? So the refresh token cookie is only sent to /refresh-token and not everywhere else.
I have seen that there is the next-auth module there I can use the getSession function on serverside but since I have my own authentication service that handles all the token management I am not sure if it is a good idea or even possible to wire my own authentication system with next-auth.
Depending on how your own authentication system works, if it adhere's to the oauth / openid-connect standards, you can simply use a custom oauth provider in next-auth.
Otherwise you could use their Credentials Provider which allows for even more customization.
Related
I used to have a custom implementation of authentication on my website. I use NestJs as backend, when I login, the backend response with access token, set the refresh token as http only cookie restricted on the refresh path and once the access Token has expires it will refresh the access token. Now that I use NextAuth, Nest can't set the cookie anymore. I was wondering what is the best practice for the refresh token ? Should I transfer the cookie to the front ?
Doesn't bother me to change the logic and backend, just want the most secure and best practice.
Now that I use NextAuth, Nest can't set the cookie anymore
Nest will send the cookie to the browser. and since you are using next you will at some point send Requests from inside getStaticProps or getServerSidePros but those functions are running on the server so they do not have any relation with the browser therefore they will not send back the cookie.
what I sugesst is to also send your refreshToken in the response and store both in next-auth session so you can access them from wherever you want inside your next app using useSession()
Doesn't bother me to change the logic
not a lot
just want the most secure and best practice
storing JWT tokens securely in the browser is impossible. see here
I'm trying to integrate one App built with Next.js and Salesforce Marketing Cloud. This integration use an OAuth. After the user had logged in, he is redirected back to the Next.js App with the authorization code, then a request is sent (with the code) requiring an access and refresh token.
What is the best or correct (or secure) way to store the access and refresh token?
Can it be stored in the client? Or Should be stored in the ServerSide (in Next.js), creating a session with an HttpOnly cookie?
HttpOnly cookie storage with CSRF tokens is the best way to store jwt tokens.
I have a Hasura server running and firebase-functions. On the frontend I have angular.
I have a working login function that gets the jwt token and the refreshtoken. However I would like to save them in a serverside HttpOnly cookie and make a silent refresh from the client.
This explains the theory of it: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/
but not the practice.
How do I create such a token in my login function in firebase? And what do I have to set up in Hasura?
It seems the article you mention, explains that the refresh token process is done by having a separate server (outside of Hasura) that handles creating and refreshing the refresh token. On the frontend you constantly hit that server to keep refreshing the jwt and refresh token. This can be done by having a setInterval/setTimeout or (better) using an axios/fetch interceptor on your requests. The idea is to have the jwt and refresh token valid by the time you make the request to Hasura.
I have found many links but I didn't get the solution for my problem.
I am trying to implement the jwt refresh token in asp.net core.
For storing the refresh token, I have created the table.
Based on the jwt suggestion, for SPA application, we should not expose refresh token to the client. https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
So I have planned like,
On user login, create the access token and share to the client
Create a refresh token for the access token and store it in the database and store it in HTTP only cookie
When user access to the authorized controller and action, If access token expire, I want to generate new token based on refresh token.
But,
In many places, I have found like, user will send a request. If it is unauthorised, then user will request for the new access token with the stored refresh token (local storage or something else) and again call to the valid api request.
I don't want to that as mentioned in the last paragraph(is that right one?).
When user send a request, if it is invalid, I want to validate the token in the server side itself and need to provide new access token and proceed with the last api call.
Is there any solution for this implementation like interpreting the authorize and validate?
In my opinion , it is dangerous to use/keep refresh token in SPA apps. Refresh token is powerful instrument , which is almost as powerful as the password itself . Store it in cookies or localStorage and both of these options are inherently insecure as they’re vulnerable to CSRF or XSS attacks against the client application . So i think it's better to just keep access token and do silent sign-in to renew it when access token expires.
So i don't think it's a good idea to return and use refresh token if client app is SPA application even using Code + PKCE .
I'm developing a web application using symfony and JWT token for authentication. For preventing XSS, JWT token is stored in cookies with HttpOnly attribute. And for preventing CSRF, I used random csrf token. This token are stored in cookie and JWT token (encrypted). What I want to know is, is it necessary to renew csrf token in every response? Whats the best implementation?
Here's my settings in details:
We've got a single page app. Most requests will be sent using ajax.
The user authenticates using POST.
On successful authentication, the server will generate random csrf token then store it in the cookies (HttpOnly) and inside JWT payload. Before it is stored in JWT payload, the csrf token will be encrypted.
After JWT token is encoded, it will be stored in cookies (HttpOnly)
Evertime user request to access another page, the server will validate the csrf token in cookies dan JWT token when JWT token decoded.
LocalStorage is not used because it is accessible through javascript
Generally there is no need to renew CSRF token at every request.
BUT let's see what happens in your setting:
you store your JWT as well as CSRF token in cookie,
you visit malicious website that provoques a malicious request with malicious data to your site,
your browser attaches a cookie to this request with JWT+CSRF,
your security is broken.
So you must not put CSRF token in cookie because it is useless whether you renew it or not.
If you use "single page application" it would be better to pass JWT in Authorization header. That makes CSRF-attack impossible (watch out anohter threats).
If you use "classical web application" it would be better to use "classical" CSRF tokens and "classical" session identifiers.