Develop Reference

Add token to src tag requests Angular 8

I'm creating an website where users can load another website i'm developing after logging in. When authorized, the users gets a JWT token, and this token is sent in the header with every request, just like any webapplication with JWT token authorization.
The problem is that I only want to send the sensitive page content to the user that is authorized. The authorization in the backend is already working with normal API calls, but I can't intercept calls made by the system itself when encountering a "src" tag for example.
The HTML file is requested like this (for convenience the header token is added here instead of in a seperate interceptor file):
redirect(response) {
console.log(response);
if(response.isAdmin) {
const headers = new HttpHeaders().set("Authorization", "Bearer " + response.token);
this.http.get("AdminPage", {headers: headers, responseType: "text"}).subscribe(response => {
// response is the HTML file
const win = window.open("", "_self");
win.document.documentElement.innerHTML = response;
});
} else {
// The users page will be loaded here just like above, with another path
// TODO
}
}
The HTML file is loaded, but when it encounters the "src" tags in it, it will request the files from the server, but the server won't respond because there is no JWT token in the request.
Is there any way to intercept this calls too? Or is there a better way to accomplish this?
(I don't know if its relevant, but my backend is written in ASPNET.Core)

You can put it as Get parameter like that
<img src="http://img.com?token=<token>"/>
Or you can use cookies like #matt suggested

It turns out it is really easy. You can just store your JWT token inside a cookie using the following code inside the controller in the backend (in ASPNET.Core):
CookieOptions cookieOptions = new CookieOptions();
cookieOptions.HttpOnly = true;
Response.Cookies.Append("auth_token", user.Token, cookieOptions);
And you can retreive the token inside the authorization middleware like this:
string token = context.Request.Cookies["auth_token"];
It is also more secure then storing it inside local/session storage because of XSS attacks.
I've read about it here:
https://www.c-sharpcorner.com/article/asp-net-core-working-with-cookie/
And here:
https://blog.logrocket.com/jwt-authentication-best-practices/
With the cookie, you don't even need to intercept the http request in the frontend, because the cookie is sent automatically with every request.
credits to #Matt Davis

serverside rendering with no client-side javascript

I am trying to create an application that can post data both through ajax and through traditional form requests. I am surprised by the lack of information I am finding online about the topic. I guess these days we all assume we have access to client side JS?
I went with express-session, but am getting frustrated at how hard it is to determine what's actually happening. From what I can understand it's cacheing cookie data on the client and somehow including those in requests automatically? Then is it safe to assume that this format will NOT work without client-side javascript support?
Given a form like this:
<form method="post" action="/create">
<input name="value1" onChange={this.handleInput} value={this.state.value1} />
<button onClick={this.submitForm}
</form>
My requests sent via ajax will pass auth (due to having session data):
event.preventDefault();
postUrl(`/create`, {value1: this.state.value1})
.then(jsonRes => {
// works
});
being picked up by auth middleware which uses express session and passport:
module.exports.secured = (loginUrl = "/employers") => {
return (req, res, next) => {
if ( (req.isAuthenticated()) ) { return next(); }
req.session.returnTo = req.originalUrl;
res.redirect(loginUrl);
return next();
};
};
which protect a pretty simple api route for creating:
router.post('/create', secured(), (req, res) => {
My thinking is that even if JS is enabled, I could handle the request at this route, but the problem is with authenticating.
What can I do to get my session data sent over in these 'non-js' requests?
I remember in traditional webstacks like Rails or PHP some sort of token is rendered into the form in a hidden field or in the action on render. If this would work, does anyone know how to get the 'vital data' so to speak out of the express session to send as the token? Not possible?
Looking in req.cookies or req.session of the req object that gets parsed in the serverside render, I do not see anything that would be useful for this.

What can I do to get my session data sent over in these 'non-js' requests?
Ussually the response to your login would send a Set-Cookie header to indicate to the client that it should store said cookie, implying it would be used to identify himself
Who stores cookies? its not javascript but the browser, so if you used curl or a scraper , your clients would have to fetch the cookie returned and include it in subsequent requests
What you mention about a token in the form is not for authentication but for cross site request forgery, meaning that since you served a token (and stored it somehow server side) you would only accept a login request including said token (proving someone navigated to your site's login page) so as to prevent other websites or clients who didnt went to your login to attempt POSTing (ie: a scraper )
Also, sessions dont necessarily mean authentication, modern frameworks tend to issue a session regardless if authenticated

Nodejs authorization approaches

Before I have to say that I've found some post related this question but not fully answered.
So I implement a nodejs REST API server, DB with mongoDB, however about authentication i understand the idea, with jwt token it work perfect.
/api/login
you get response with token. now you can request resource with this token
for example.
api/posts/:user_id
get all your posts...No problem! query with mongoose findBy.. bla bla!
so for authorization in this case it's easy, check for query param user_id is equal to token (token parse with user_id). boom resources is secure.
but in case that I have some resources they're not reference by user_id, What is best practice to protect this resources?!
example
api/settings/:settings_id/emails
imagine that I know the setting_id of other user, and i authenticated with token. so how server will know this resources is not allowed for me?

First, you should do more to protect the token in the first place. When you issue a token after a user logs in you should store their token on either web storage like sessionStrorage if https is enforced or use an httpOnly cookie (You can add a user-agent/geoip fingerprint in addition to the user_id upon signing this token to add an additional layer of security). Then, when a user makes a request for a protected resource, you can match the fingerprint and user_id you signed the token with to the user they are making the request in behalf of.
You could use something like passport-jwt as a middleware in express to require authentication on routes. In passport, you define an extractor handler that basically tells it where to look to see if the user has a token and if they do and it validates it adds the req.user property that you can use on subsequent requests to determine the user_id of the token bearer. So basically with this approach, you know the user_id on every request which lets you compare that with the user information they are requesting.
app.post('/settings/:settings_id/emails', passport.authenticate('jwt', { session: false }),
function(req, res) {
res.send(req.user.id);
}
);

What is the best way to access the JWT from node?

I have implemented JWT authentication using Node.js. When the user signs in, Node.js signs/creates a JWT and sends it back. Thereafter, it is stored in the localStorage. Now, this is probably where I am going wrong, but... to move forward, I make use of the express router, and within the router code (which is obviously at the node level) I want to be able to access the token (which is in localStorage) so that I can make a call to the API for further data. However, I just realised that localStorage is at the client-end and that node/express/router doesn't recognise localStorage. So I am stuck. Obviously, I am doing something fundamentally wrong... I should not need to access localStorage from the express router file. Perhaps, I should really be making the API calls not from the express router file, but from client side.
Any hints/directions?

localstorage is bad way to save token. you should save token in cookies and use then where you want.
EXAMPLE:
new Cookies(req,res).set('access_token',token,{
httpOnly: true,
secure: true // for your production environment
});
and then read:
var token = new Cookies(req,res).get('access_token');

You need to send the JWT that is stored on the client side every time you make an API request to the server side.
https://jwt.io/introduction/
Scroll down to the section How do JSON Web Tokens work? The JWT should be sent in the header of the API calls in the form:
Authorization: Bearer <token>
How you do this depends on how exactly you'll send the HTTP requests to the API, but it should be pretty simple in any respects. You can find out about how to add Headers to an angular $http request at this link:
https://docs.angularjs.org/api/ng/service/$http
Then it's up for each of your authenticated express routes to check the headers, pull the JWT out, ensure that it's valid, and then proceed with the request (or halt it if the JWT is invalid).

Token based authorization in nodejs/ExpressJs and Angular(Single Page Application)

In my application,while registering the users i am saving username,password and jwt generated token with these fields in MONGO DB.When user tries to login with correct credentials then i will send the response with stored token.Then at client side(In my controller) i am using the localstorage to store the token so that i can send the same token for each and every request sent by the client.But I found some issues regarding this procedure:
I am generating same token for one user every time.So if any third person is able to get the token then he can access the restricted page.
Am i wasting space in db by storing the generated token in MONGODB
Can Anyone access the token stored in localstorage other than the user.
for each and every request in my single page application,I am again querying mongodb to get the token for that user and validating.Here,I am checking both client side and server side.
I am using jwt to generate tokens,Node,Express,Mongoose in my application
Am i following the good procedure.If not,can you please provide the solution for my approach or any new approach.
I have searched many sites for token based authorization and session based authorization,But nothing worked for me.
Note:I am beginner for Nodejs,AngularjS

You should store token in advanced key-value cache tool like: Redis
That would improve performance remarkably.
You will get token from database for 1st time then it should be stored in Redis. I used to set token as key and username as value. Next request , the token will be given from cache. with Redis you can set expire for token.

When a user registers, you would need to generate a JWT like you're doing now. That's OK. You don't need to save it to the database however. You didn't ask but I assume that the password should not be stored in clear text. You can use something bcrypt to encrypt before saving it to the database.
When user tries to login with correct credentials then i will send the response with stored token
Yes, that's correct way to do.
Then at client side(In my controller) i am using the localstorage to store the token so that i can send the same token for each and every request sent by the client.
Yes, on the client side, you can save the JWT to local storage and send it in subsequent requests to the server.
Now your bullet points:
So that you won't have the same JWT each time, you can include an "exp" claim in the payload (I'm assuming you're using something like jwt-simple to generate a JWT). Something like:
var payload = {
sub: account.username,
exp: moment().add(10, 'days').unix()
};
var token = jwt.encode(payload, "secret");
You don't need to store the JWTs in the database. In some cases, the token issuers (the authorization servers) are not the same as the resource servers. The resource servers only receives the JWTs in a request but there's no way for the resource servers to touch the database used by the authorization servers. Side note: If you eventually need to support refresh tokens, i.e. the JWTs that you hand to the clients will need to eventually expire, then you can store the refresh token in a database. Refresh tokens are not the same as JWTs (access tokens). The complexity to support refresh tokens will increase.
Local storage is not where you store passwords, but it can be used to store JWTs. For that very reason, a JWT must and should expire after a certain time.
Not sure what you mean by saying you check both client side and server side. When the client needs to access a resource (again it's fair to assume that the resource server might not be the same as the authorization server), the only thing that the resource server is passed is the JWT. Anyone can decode a JWT. For example, try to paste your JWT on this site http://jwt.io/. That's why a JWT should not contain any sensitive data. But if the resource server knows the secret that the authorization server uses when it encode the JWT, the resource server can verify the signature. Back to your third bullet, that's why it's OK to store the JWT in local storage of the client.
Update I'm updating this to answer to some of your questions in the comment box.
User clicks on 'Login' button triggers the Angular controller to post a request to the server, something like:
$http.post(url, {
username: $scope.username,
password: $scope.password
}).success(function(res) { ... })
Server receives the POST request, it checks username/password, then it generates a JWT, and sends back to the browser. Note that it does not have to save the JWT to the database. The code would be something like
var payload = {
sub: account.username,
exp: moment().add(10, 'days').unix()
};
var token = jwt.encode(payload, "secret");
res.status(200).json({
token: token
});
Back on the client side, in the success() callback above, now you can save the JWT in local storage:
.success(function(res) { $window.localStorage.setItem('accessJWT', res.token) })
The user is now authenticated. Now when user wants to access a protected resource, user don't have to provide username/password. With the JWT which can be retrieved from local storage, the client can now put the JWT in the Authorization header of the request using the bearer scheme, and sends the request to the server. In code, it would like:
headers.Authorization = 'Bearer ' + token;
The server receives the request. Again, this server receiving this request does not have to be the same as the server which generates the JWT above. The 2 servers can be in 2 different continents. Even if you save the JWT above, that does not do any good to this server which can not access the database where the JWT is stored. But this server can pull out the bearer token from the header of the request, validates the token and carries on with the normal tasks.
Hope this helps.

You do not want to store the JWT in mongoose because it appears in headers when logging in. You first generate a token then hash it using a module like crypto.
There are different ways to do this and they all use Passport which handles the tokens. Here's an example project Satellizer
I would recommend you generate the angular-fullstack project. Then go through the server/auth folder and the client/account folder. You will see how to securely handle authentication in a MEAN based app.