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
Related
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.
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 am using React Native fetch() in order to authenticate against a REST API which uses session cookies.
The session cookie received upon sign-in is automatically sent back with every request, and this works fine.
However, if I sign in and then quit the app, upon starting the app again the session cookie seems to have been lost.
How can I persist the sign-in cookie so it's stil there after an app unload?
There are several cookie-based react-native components out there. One of these might be helpful to you.
https://github.com/joeferraro/react-native-cookies
https://github.com/shimohq/react-native-cookie
https://github.com/beefe/react-native-cookiemanager
I've heard of some solutions which use the webview to persist cookie-based authentication as well. But if you can, I suggest looking into a stateless method of auth persistence, something like JWT for instance. You can then cache the key in local storage.
In the end, it might be easiest if you just cache the cookie's session variable into local storage yourself, then manually inject the cookie header into your fetch() requests yourself on every request.
Did you try?
fetch(url, {
credentials: 'include'
})
Source