As I know, storing jwt tokens in local storage/session storage is not secure because it can be accessed with javascript (XSS attacks), so the secure way is to store it in httpOnly cookie.
So why does Firebase auth provide every persistence method except the httpOnly one?
Related
I completely don't understand the next-auth documentation.
I understand you can use both JWT and sessions, but how do you tell next-auth which one you're using?
And where does next-auth store its sessions or JWTs? On the server or client-side?
NextAuth.js uses a JWT to save the user's session by default, when a database adapter is not used.
NextAuth.js by default uses JSON Web Tokens for saving the user's
session. However, if you use a database adapter, the database will be
used to persist the user's session. You can force the usage of JWT
when using a database through the configuration options. Since v4 all
our JWT tokens are now encrypted by default with A256GCM.
The JWT is stored in an httpOnly cookie, not accessible on the client-side.
You can use JWT to securely store information you do not mind the
client knowing even without encryption, as the JWT is stored in a
server-readable-only cookie so data in the JWT is not accessible to
third party JavaScript running on your site.
This is documented in NextAuth.js JSON Web Tokens FAQ section.
I realized firebase auth for flutter web stores the user's access token in index DB. I thought this is not safe. I understand the access token must be persistent to maintain the authentication state. But based on the research I made here and here, I understood storing access tokens in local storage, session storage, and index DB are all vulnerable to XSS attacks therefore httpOnly cookies should be used instead.
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'm learning about Basic Authentication and Jwt Authentication with Java and Spring and I want to ask you if basic authentication is a session based authentication?
I know that in a session based authentication, when the client log in, a sessionId is stored in cookie on the client browser and after that when the client make another request, the server compares the sessionId with the data stored in the memory of the server. And also I want to ask you how is the sessionId sent from client browser to server? Is it sent in the header like a token or how?
And the last question is how the server validate the Jwt token? I know that in case of session authentication, the sessionId sent from client is compared with the data from the memory of the server. But what's happen in case of Jwt authentication? The token is sent with the header and I know that the server validate it and there is no data in the memory of the server. Then how the server compares the token? Any feedback will be apreciated! Thank you!
if basic authentication is a session based authentication?
I know that in a session based authentication
well then why do you ask?
Actually - basic authentication means, that the user credentials(username and password) are sent in the Authorization http header
Authorization: Basic base64(username:password)
The server may or may not use a session cookie. Session cookie may be used with other authentication means or even without any authentication
how is the sessionId sent from client browser to server?
As a session cookie A session cookie is sent as an http header which browser treats as session-persistent
And the last question is how the server validate the Jwt token?
The JWT token should be signed. Note the token has usually 3 parts
header.body.signature
the header specifies a signature type (an asymmetric key or shared secret) and the signature is authenticated (signed or hmac-ed) header and content.
So - the server must validate the issuer, expiration and the signature.
So the server (service provider) doesn't need know the client's identity upfront. The service provider needs to know the issuer's (authentication service which issues the jwt token) public key or shared secret key.
After the jwt validation the service can assume the caller's identity based on the information in the jwt token.
why Jwt is more recommended?
It depends in the use case. (everything has its pros and cons)
I'd recommend using jwt in a distributed and/or microservice architecture. The service doesn't need to access the credentials or to authenticate the user.
In the basic authentication we need to send the username and password for every request.
In the session authentication we will send username and password at initial request. Then from server response we get the session id which stores in browser and gonna use that for requests.
In the token authentication we will send username and password at initial request. Then from server response we get the token and gonna use that for requests.
hope u got it!!