I've been diving into authentication between Angular and Express, and decided on using token auth with JWTs and the npm jsonwebtoken package. I've got everything set up on the server side and am receiving the token on the client side, but now I need to know how to make it send the token with every request.
From what I've found, most resources out there say to use an $http interceptor to transform every outgoing request. But people at work have always used $httpProvider.headers.defaults.common["Auth"] = token in a .config block, which seems a lot more straightforward to me. Here's a blog explaining how to do it both ways.
But the accepted answer on this stackoverflow post says it would be better to use interceptors, but he doesn't give a reason why.
Any insight would be helpful.
After a bunch more research and a conversation on Reddit, it seems like the best way to do it is through the interceptor. Doing the setup in the .config or .run blocks may be good for checking if the user is already authenticated when they first load the app (if there is a token in local storage), but won't be possible for handling dynamic changes like logging out or logging in after the app is loaded. I'm pretty sure you could do it through the $http default headers, but might as well just do it in one place.
Hopefully this helps someone in the future!
Related
I'm trying to add a bearer JWT token to a swagger request upon login of an account but I can't seem to get it working. The documentation leaves a lot to be desired.
const SWAGGER_CLIENT = SwaggerClient(".../api.yml");
const carsResponse = await SWAGGER_CLIENT.client.execute({ operationId: "getCars" }); // I need { Authorizations: Bearer ${token}} here
If it's not possible to add it there then I can always create the client above with the token upon a successful login.
I think the issue is the syntax more than anything. There is virtually no documentation on how to use the .execute() method which is very frustrating. FWIW; I'm using the execute method and passing in tag names to make it more reusable than using the generated functions e.g., getCars(), addCar() etc. I don't know if this is the "right" way to use Swagger but it makes sense to me.
Is is possible to add it globally so I needn't include it in every request? The token will need to be added upon a successful login. It's a CRA application using Redux.
If somebody could explain, or provide a small example of adding the authorization bearer token to the request above that be fantastic and greatly appreciated.
Thanks all.
We will be renaming Try It Out Executor to HTTP client for OAS operations. Thanks for your input!
I've built an API with Node.js/Express which I'm currently using alongside my Angular app.
For authentication, I have a username/password setup which then returns a JWT which is happily used.
Now, I've been spending some time (and reading such Stormpath articles) I want to use cookies rather than localstorage for storing these JWTs. And thats where my questions begin.
So what I've essentially done thus far is updated the saving and reading, e.g. for saving from $window.localStorage['jwtToken'] = token; to $cookies.put('jwtToken', token);. And for reading, from return $window.localStorage['jwtToken']; to return $cookies.get('jwtToken');
At this stage I was wondering whether someone could help me understand a few bits, kindly correct and inform me of any missing parts of knowledge:
1 - So in addition to the actual saving and reading as above, is there anything else I need to explicitly set - what I think is HttpOnly cookie flag (so JS can't access the cookie data.
1b - Do i also need to update my node API so that instead of returning res.json its doing res.cookie?
2 - Do i also need to set the Secure cookie flag so that its sent via HTTPs. So at present i wrote a simple authInterceptor that attaches a header with each request: config.headers['x-access-token'] = token;. Is this where that secure cookie flag would be set?
3 - So using cookies am i correct to understand XSS attacks are minimised as JS can't touch the cookies however I need to concentrate on CSRF. For this I am thinking of using this CSRF middleware on my node api server side and use this alongside Angulars built in XSRF-TOKEN as described here. Is this a good implementation to follow?
4 - When looking at Chrome inspector, I see the cookie containing the JWT, however the HTTP/Secure/Same-Site are all untucked, also the Expires says Session. Could someone please explain what this means:
Sigh, I think thats it, sorry if its a little long winded. Hopefully others can gain from what we learn here.
Any help appreciated.
Thanks.
If you set HttpOnly $cookies.get('jwtToken'); wouldn't work...
1b. Don't understand the question here...
The Secure flag tells the browser to only include the cookie if the request is an HTTPS request. You can still make HTTP requests, but the cookie will not be included. document.cookie = "name=somevalue;secure"
If you set HttpOnly so that JavaScript can't read the cookie, that's some protection, but if you have XSS, then all bets are off. The injected script could still perform network requests, and do exactly what your code is doing to include the CSRF tokens. You still need CSRF-protection, but in most cases XSS means circumvention of CSRF-protection.
Session means the cookie will be deleted automatically if you close the browser (which people don't really do all that often anymore).
I have inherited a Ionic app which uses ng-token-auth+devise_token_auth to handle the authentication and the session between front and back.
What happens is quite strange. Sometimes (specially with slow connections) the request (or the response) get lost and after that I get only 401 http errors.
I know that that everytime I send a request the token expires, but when the xhr request is cancelled (by the server I suppose, or by the browser, I don't know) the token is expired without having been replaced by the new one generated by devise_token_auth gem.
I know Rails but I'm not familiar with Angular, neither Ionic and I don't know exactly where to look.
After reading a lot of SO answers where noone seems having my problem (which happens locally and in staging/production), I checked the following
storage is set as localStorage.
config.batch_request_buffer_throttle = 20.seconds
there is no pattern between cancelled requests, sometimes I perform get for the username, sometimes a post or a put to a comment.
Is not a CORS problem because it would happen always or never. (moreover I'm using a proxy as explained in ionic blog)
Maybe it could be related to provisional headers chrome bug. But, how can I be sure?
What puzzles my is that it happens only sometimes and not always. (and there are no errors in the backend)
The only workaround I have found in the devise_token_auth documentation is change config.change_headers_on_each_request to false avoiding in this way the regeneration of the token.
But I don't like this solution because I think it hides the real problem in an insecure way instead of solving the token loss. Any suggestion?
Kindly, please check this thing:
Version: which version of this gem (and ng-token-auth, jToker or Angular2-Token if applicable) are you using?
Request and response headers: these can be found in the "Network" tab of your browser's web inspector.
Rails Stacktrace: this can be found in the log/development.log of your API.
Environmental Info: How is your application different from the reference implementation?
This may include (but is not limited to) the following details:
Routes: are you using some crazy namespace, scope, or constraint?
Gems: are you using MongoDB, Grape, RailsApi, ActiveAdmin, etc.?
Custom Overrides: what have you done in terms of [custom controller overrides]
5?
Custom Frontend: are you using ng-token-auth, jToker, Angular2-
Token, or something else?
I need some advice regarding using session tokens to authenticate users. I am building an AngularJS app which uses an API to tie in with the backend. I am only building the front end, not the backend. The documentation states that all calls to the API have a session token attached in the body of the request (POST).
I would like to know about the security of storing this token in localStorage. That is where I am storing it now and retrieving and attaching it to each API request. After login, the server sends the session token in the body and I save it from there.
There is no documentation about an x-access-token header that should be sent with the request made to the server. It is not being checked server side. What are the implications of this? I feel that it is susceptible to attacks without this added layer of security.
My main concern is the security of this setup. I want to know what the best setup is to make sure this app is as secure as possible and recommend changes to the way the backend is setup to facilitate this.
Thanks!
As you tell, you are only working on the UI part and not the backend. It is up to the backend team to ensure headers are properly evaluated and security is enforced (btw request headers do not belong to request body). Just put the token into the x-access-token header as they tell.
Storing the token inside the localStorage gives you a little more control over the cookie: You will not accidentally send it to unnecessary URLs. However, older browsers do not support it - you may need to use a shim for that.
In a case of SPA, you may consider not storing the token at all: It could be fetched each time your application is accessed and then stored within a service in angularjs, but it depends how your fetch/login operation is implemented (is it always interactive, how long does it take, etc).
I would suggest use $cookies rather than localstorage. As localstorage does not support some legacy browser.
I am using cookies to store token in my project
It is common to authenticate to web services using an authorization header which contains a secret token. And since the security of this mechanism depends on the token to be secret care should be taken that this token is not leaked.
There are countless tutorials on the web which explains how such an authorization header can be set using angular and least the ones that I have actually read use an $http interceptor and now one discusses that the token is not leaked.
There are some public and some private APIs out there which can be talked to cross domain thanks to CORS. And obviously I do not want to send my internal authorization tokens on any of those requests.
Some other techniques come to mind such as setting the token manually only on each and every request, but that means lots of duplicate code. The $http server could be wrapped in an $authenticatedHttp service so that it is always appearent from the object used whether it is the authenticated service or the normal one. However the $http service has so many methods to be wrapped.
Is there a better solution?
UPDATE
From the answers I have the impression that my question was not understood. I try it with a more concrete example:
I have a private web page. People have to login with username/password and let's say for simplicity's sake that we use HTTP basic auth, so username/password are bas64 encoded and are transmitted on every request in the HTTP header "Authorization". So far there is no problem.
But there is this great&free weather widget. I can retrieve the current weather information in JSON format from https://myWhateverWeatherService.tld/weather.json. After the login to my private web service I also retrieve the weather information (CORS allows me to do this).
The problem is that even though myWhateverWeatherService.tld does not require any authentication at all, angular's $http service will still append the Authorization header. And I don't trust the guys at myWhateverWeatherService.tld. Maybe they just set up the service so they can steal Authorization token and do lot's of nasty stuff with them.
I need some reliable way to deal with that. I already thought about checking the url with some regex in the interceptor. This is possible, but it is also not to difficult to forget about a certain case that my regex will miss.
The token is always sent through the wire, I guess that is the most vulnerable part of it.
Since the token must always be present on the http header itself, the only way to make the request more secure is to encrypt the whole request, and for that you should use SSL.
If you are concerned about the safety of storing the token on the client machine, you can keep it only on the browser´s memory, without persisting it on a localstorage or something like that. So every time the user closes the browser and open it again, s/he must log in.