I am new to web authentication and need some clarification.
I have seen people implementing token based authentication alongside angularjs $rootscope to save logged-in user information.
Why need to attach a token to Headers at every request if the angularjs application will only check its own variable to identify that the user logged in?
Likewise, if one has a token in every Headers, why simply check the Headers on client side to know if the user has logged in? If so, I do not see why one uses $rootscope to save logged-in user's info.
Thank you in advance.
I think you unintentionally nailed it when you said "the angularjs application will only check its own variable to identify that the user logged in".
The frontend will usually just trust that whatever kind of token it has is valid, since there is no way to do an independent verification of it (remember, there is no such thing as frontend security). The backend however can't do that, it needs to actually verify on each request that the user is who he/she claims to be, otherwise your application is not secure. Hence you send the token on each requests so that the backend can check it.
If you simply trusted the frontend to say who is logged in or not then nothing would stop an attacker from simply bypassing that check using javascript and take control of any account they wanted. Validation always needs to be done backend.
As for saving it in rootScope, that is mostly just a convenience thing people do for things they always want available so they don't need to get the data in all controllers. I tend to use an abstract state in ui-router or a shared factory for that instead, but it amounts to mostly the same thing.
Related
I'm new to reactjs and I've ben trying to understand how the authentication token works to protect routes. In various tutorials people get that token from an api when logging in a user, and then store it along with a "isAuthenticated" variable set to true in localStorage. Then when routing they check if isAuthenticated is true, without any api call to verify the token. Is that safe? I was trying to implement authorization in the same way, by just adding some isAuthorized variable, but can't both of these be tampered with since react works client side?
Of course they can. Whatever is on the client is fully controlled by the user. There is no "client-side authorization". Such features (access control to certain functionality on the client) is usually a user experience feature, like why show something to the user that won't work anyway.
All authorization must be done server-side.
This inherently means that it's usually ok to have page structures (views) without data in the client for anybody to see, the point is that data from the backend will be authorized and will only be available to appropriate users.
I have an application that uses express.js as the server side language and React on the front-end. I use passport.js to authenticate routes in the server, using local login and facebook strategies (no JWT). I use express-session to manage the session, which seems straight forward ( or insufficient, which I do not know yet, for my case, as its work in progress ).
My requirement is to hide/show few links in the Header component.
i.e.,
Log In
Sign Up
should show up in index page, when user has not logged in, but hidden when he is logged in. Likewise, few links should be hidden when the user is not yet logged in.
What is the best wat to check this from the client? Making an AJAX call is not ideal, as I may have more use cases of checking if the user session is valid from the client.
I can see the default connect.sid cookie, which the express creates, but how do I make use of it, or is there a best way for the client to know that the user is already logged in.
You have a couple options. Here are some:
You can check for the presence of a different cookie in the browser, and use that as your metric for whether or not you are "logged in". Your browser won't know if the session has expired server side, so you still have to account for the fact that you may be logged out and not know it. Additionally, you have to be sure to clear this cookie when logging out and set it when logging in.
When starting, your browser can make a AJAX request to get the currently logged in user. This might be useful for all sorts of things, such as displaying the user's name when logged in. You really only need to do this once (on page load and on login), then keep track of the user's login state stored in memory. You mentioned you don't want to do this, but it is fairly common.
When loading the page, you can inject the user into the page. For example, when the page loads there will be a <script> tag containing window.currentUser = null or an object representing the user. You can use this to "bootstrap" the login state without needing an AJAX request.
To clarify, you can't use the connect.sid cookie by itself because this cookie is just the ID of the session, not the session data itself. Only the server knows the session data that's being stored for that user, not the client. You need some way aside from this cookie for the server to tell the client that it's logged in, and the client to keep track of that state.
If you want the client to know from the ID component itself, you'll want to look at token options like JWTs.
In a WebApp development with AngularJS which uses token validation for authentication purposes, what's the best way to do this validation? For example:
Validate the Token every time I have a route transition. For this I have to make a rest call for everytime I want to validate.
Validate the token just one time, with one rest call, and then store the token in local storage. (The token itself just have a boolean telling if it is authenticated or not)
My concern is to not make a rest call in every route transaction, I don't want to consume that much of http traffic. But, if there isn't another way, I will do that.
If we look into what a JSON Web Token (JWT) is (although you're not specifically referring to JWT, but simply to "token"), you will realize that once you got a JWT you do not need to validate it every time you make a transition in the client app (Angular). This is because JWT are usually signed, so the server can be sure the senders (in this case the Angular app) are who they say they are when they make a request.
What you need to do is to send the JWT on every request in a header to the API server every time you try to consume a resource. The server is in charge of checking that you are sending a valid JWT and to assign the proper permissions to that request in order to get access to the resources.
Concluding (and answering your questions)
1.Validate the Token every time I have a route transition. For this I
have to make a rest call for every time I want to validate.
No, this is useless, since the given token is already signed by the server. If the token is manipulated in the client in any way the resource server will know it and will answer with the proper HTTP Status Code (usually a 401 HTTP Status).
What you can do is, in case the server respond with a 401, you can use a Refresh Token (if the server provides it) in order to get a new access token and use it again on every request. This way the final user will never know what's going on behind scenes (and won't see a login form again) because you won't ask him/her again about the username and password.
2.Validate the token just one time, with one rest call, and then store the token in local storage. (The token itself just have a boolean
telling if it is authenticated or not)
This is a correct approach (and used by most people), this way you do not overload the traffic with unnecessary requests. Actually, when you get the access token, you do not need to validate it because as I said before the token itself is Self-contained (it contains all the required information about the user and other necessary data the token provider considers important).
If I were you I would read a lot about this since there is much more to get to know than what any answerer can put together in a single answer here on SO (I put some links to sources I've used and which describe pretty well these topics).
Bear in mind that all theses behaviors can be modified according to your needs and not all of them have to be the way I just described. I just put some examples of how it could be.
The image below will give you a big picture about all these matters I just described.
I am using laravel 5 and angular js and JWT authentication for logging and registering my users. But there is nothing mentioned about to facilitate users with remember me functionality and also allow users to reset password when forgotten password.
I researched a lot and didn't find exactly what I need though the answer in following link is helpful but inadequate for me to proceed.
Laravel 5 Password Reset with Angular View
Kindly provide any information and links that would be helpful.
Thanks in advance! :)
To Answer from a JWT perspective.
Remember me is essentially asking the user how long they want to login for. Depending on the security requirements and typical usage patterns of your users, short sessions are often from 15 minutes and up to a browser session. Long sessions (selecting Remember me) can be anything from 24hours to a year.
The JWT issuer can set the exp claim (expiration time of the token) differently depending on the user's selection of the 'Remember Me' checkbox.
If you're intending the 'Remember Me' to last longer than a single browser session, the simplest way is to store the token in a cookie. This means the cookie also needs to have the following properties set: httponly, secure, and expires (with the same expiry time as the exp claim from the token).
Rest Password implementations come in many shapes and sizes depending on your requirements. These are not directly related to JWTs as they come before the JWT issuer will issue a token.
You're asking for something that will need to be handled specifically for your case. The way most "remember me" systems work (including Laravel) is via storing a cookie on the user's device. That cookie is then used to authenticate automatically when the user returns. JWT is different as you are given a token, rather than a cookie, that you pass back to the server in a header. They are both essentially strings of letters and numbers, but you'll specifically have to store the JWT token on the user's browser in order for a "remember me" type of functionality. You might do this in the Angular app using localStorage or some other similar front-end practice.
For the forgotten password, you can submit the same form fields that are default to Laravel and simply override how the PasswordController returns the response; in this case needing a JSON response rather than a redirect.
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.