I get JWT token from other api and then want to send it ti my node.js backend and write it in httpOnly cookie.
How to add some data(JWT token) to HttpOnly cookie with koa-generic-session?
koa uses the cookies module where options are simply passed.
docs https://github.com/pillarjs/cookies
Related
What I am trying to achieve
Let's say there is a web app that allows users to log in with Google.
The newest google identity services provide jwt tokens on successful Logins.
Instead of local or session storage, I decided I will be storing the jwt in client-side memory, and keep a refresh_token in a httpOnly secure cookie
Example:
After successful login, the web app will hit the backend /authenticate which will decode the jwt token, and it will keep add that to a map(refresh_token → jwt) and it will respond with that refresh_token
The web client will then save that refresh_token in a httpOnly cookie and it will instantiate a socket connection (using that refresh_token in the handshake)
the actual jwt remains in memory, and it is not prone to attacks
When a user refreshes the page, that refresh_token will be used to defer the current jwt token, or fetch a new jwt if expired.
The socket connection will always have a refresh_token in the handshake, which is mapped onto a valid jwt token that will be checked on each socket message
Question:
If an attacker manages to grab that refresh_token, they can request a new jwt token from my server, as if they were users, supposing they know there is an endpoint on my server for that... What is the benefit of storing the jwt in-memory and the refresh_token in a httpOnly cookie?
I understand that this makes the attack process more difficult than just storing the jwt in a httpOnly cookie, but at the end of the day the refresh_token is also useful, it's just useless to the outer world.
I just trying to makes my auth flow more secure using a cookie on Laravel 5.7
Here my code
/**
* auth logic
*/
return response()->json(["status" => "logged in"], 200)->cookie('token', $token, $lifetime);
Then the cookie will be saved on the browser and will be used on every request.
On header with Axios
"cookie":"token={token}"
And I validate the auth using default middleware
Route::group(['middleware' => ['auth:api']])
But the auth:api did not recognize it, I can make custom middleware by manually detect the cookie, but I can't use the auth()->user() function on it.
Is there any solution for this?
From your sample code I believe your app is built on a stateless architecture where you have your JavaScript client and laravel api.
Now I am a bit confused as to why you do not want the client storing the token, if you just want to escape cross site scripting vulnerability (XSS) then you have to prepare to deal with cross site request forgery (CSRF) if you store the token in the browsers cookie.
Regarding the middleware not being able to find the token, by default the middleware is configured to lookup tokens in the request header (specifically the Authorization header) so if you decide to store it in the cookie, you have to find a way to change the token lookup in the api middleware which unfortunately I have not done before in laravel.
APIs don't generally store and send cookies. Therefore the api token authentication guard will not look for the token in a cookie. There are multiple options you can send it as though the easiest one in axios:
{
headers: {
Authorization: `Bearer ${token}`
}
}
Is it possible to use Google Header Auth with an API_KEY?
At the moment we are downloading files using:
https://www.googleapis.com/drive/v3/files/{fileId}?alt=media&key={our API key}
We want to migrate to using HTTP Header auth like this:
GET https://www.googleapis.com/drive/v3/files/[FILEID] HTTP/1.1
Authorization: Bearer [YOUR_ACCESS_TOKEN]
Accept: application/json
The first method uses our own API_KEY from Google Cloud Console.
The second method uses an ACCESS_TOKEN created by the user authenticating with the app with oAuth.
Is it possible to use our API_KEY for HTTP Auth? Or do we have to use the users ACCESS_TOKEN?
API key grants you access to public data only.
An access token is an authorized token which gives an application access to user data.
They are two different things.
The authorization header is used for sending authorization bearer tokens, access tokens to the server to authorize a request.
No you can not send an api key as a authorization header as it is not a bearer token. You need to authenticate your users using Oauth2 in order to get access to their data, which will give you an access token and the ability to add that as a authorization header and request access to download the users file.
I have a webapp that has a javascript page that makes ajax calls up to the webservices. The authorization scheme used for the site is JWT with bearer tokens being used in the authorization header.
However, I now realize that I am vulnerable to XSS, because the token is being stored in a cookie, and the javascript needs access to this in order to set the bearer token in it's requests. Because of this, httponly is set to false, thus meaning my token can be stolen.
So, what I would like to know is whether there is a way to protect against both CSRF and XSS whilst using ajax requests and JWTs?
I have began building an application using React JS and Laravel 5.5. I have installed the Laravel Passport and have successfully managed to log my user in and out in my React JS app - but I have been told to look into using httponly cookies for security purposes.
In my working code, I have simply stored the access token in localStorage and sent it to the api using Authorization': 'Bearer ' + token in the axios headers, and this works perfectly. However, when I set a cookie using httponly I can't fetch the value of it (which I assume is exactly the point!) - using react-cookie (from npm), if I log cookie.loadAll() to the console then the only cookie I see is a new XSRF-TOKEN cookie, but not the accessToken cookie I set. So how do I go about sending this token to the api?
Since you can't read the httpOnly cookie from JS, when getting a new token from the backend, the backend has to send the token in the response body.
Browser session cookie usage and bearer tokens are different strategies of authentication (cookie based and token based).
In my opinion they should not be mixed.
Lavavel passport supports authentication with bearer token or with cookie out of the box (see condition at TokenGuard user)
You have to use Passport::cookie for this.
In this case you will be able to set cookie and use HttpOnly flag with other attributes to secure them.
Httponly cookie as bearer token doesn't make much sense. Having cookies httponly helps to protect you and the user against XSS attack as their not readable by javascript. They can be used e.g. for storing session information and are sent when the user do e.g. a page reload.
Setting Authorization header to 'Bearer ' + token is correct way how to sent token to the api. Before using token on the api server you should always check if the token is still valid.