BoilerplateJS: recommended way to handle authorization and authentication - javascript

With BoilerplateJS setup, what is the recommended way to handle authorization and authentication?
Obviously on the server-side you'd check cookies etc to know who's logged in. But, on the client, how would you know if a user is logged in and what their username etc are?

I will share how this was done in one of the projects that used BoilerplateJS. On this project we used OAuth 2.0 for authentication.
We had a separate login page which was NOT using BoilerplateJS OR complex JS. The reason to keep it separate is that authentication may depend on URL redirection, which is not handled best with JS.
Once user is correctly authenticated, we receive the auth_token of the server session and store it as a JS variable. We used 'settings' of global Boiler.Context to store this token. Since settings are inherited to child contexts, we were able to access it from any where.
For authorization purposes, then we then downloaded a simple ACL for the logged user that contains the authorized access keys. These keys were just for client validations to show/hide controls. Real authorization was performed on backend services.
We wanted the BoilerplateJS components to be fully self contained including authentication of it. Therefore if a particular component's viewmodel receive an unauthorized 401 HTTP response from server (either not logged-in OR or session expiry) we rendered component differently there, without redirecting user to the login page.
Since we did not redirect, user was able to make use of other information on the page even the BoilerplateJS component was not actively displaying it's content. We had a rendered some error information on the component with a link to re-login.
Handling of this was done via a generic error handler we created. From component.js, we pass a error callback function to our viewmodel (you may have this on context itself too). This callback function is used by the viewmodel to notify any error occurred within it. In the case of 401 HTTP code, this handler is invoked asking component.js to render UI with error information and a link to re-login.
User clicks on the re-login URL to get back to the login page. This URL contains a back reference to the originated URL, such that user is able to get to the page where he was after authentication.

Related

secure an angular route more safely than with routeguard?

I have to create a SPA with Angular 8.
In the SPA I will have a component with a form that can only be seen if the user has permissions.
For this I had planned to use a route guard, the problem is that the guard runs in the client's browser, which does not guarantee that the component of the form is not seen by a malicious user (for example, editing the js).
There will be security in the RestAPI backend when receiving the form data (permission check and so on), but I need to make sure that the form cannot be seen by anyone who does not have permissions.
Is there a way to efficiently block the visualization of an angular component?
There is no denying that you client side code can not be accessed by malicious code alteration.
You can not do anything about it, as SPA code relies on front end so if you know the variables and can alter the functions from lets say console or otherwise, there is nothing you can do.
As far the access control goes or blocking UI elements goes, you can have strong back-end which will not authorized unauthorized access. This way only UI can be seen but the data required to function that UI will not be visible (due to back-end access control).
You can think it in logical way,
If the sensitive data is not visible then no problem if UI element is visible.
If some action button is visible to malicious user, as to perform this action you need back-end, this won't work as the malicious use wont have access to end endpoint.
Bottom line is your band-end should be very strong to handle authorized requests and separate itself from unauthorized requests.

JWT-based authentication in ASP.NET Core SPA - front-end validation

I'm currently playing around with a KnockoutJS SPA template in ASP.NET Core 2.1, and I managed to implement an authorization flow exactly as this one which was made in Angular:
https://fullstackmark.com/post/13/jwt-authentication-with-aspnet-core-2-web-api-angular-5-net-core-identity-and-facebook-login
As you can see in their User front-end service, basically the only check for whether the user is logged in on the client side is the check if the "auth_token" key exists in the client's local storage:
https://github.com/mmacneil/AngularASPNETCore2WebApiAuth/blob/master/src/src/app/shared/services/user.service.ts
this.loggedIn = !!localStorage.getItem('auth_token');
// ?? not sure if this the best way to broadcast the status but seems to resolve issue on page refresh where auth status is lost in
// header component resulting in authed user nav links disappearing despite the fact user is still logged in
Simply put, anyone can open up the browser local storage and insert a random string with the "auth_token" key and they'll be able to see everything admin-related in the UI (even though they will fail on API requests).
Can someone suggest a better flow for this? Or is the only option to send a "log in request" to the API, whenever an admin page is "opened"?
P.S. I am relatively new to the authentication schemes front, should JWT perhaps not be used for client-side content validation?
Considering JWT best practices, all your validations should be done in your back-end, since any validation coded in your web app could be read by any of your clients, resulting in a huge security flaw: anyone would know how to create a valid JWT for your application.
Is it a big problem to be possible to see your admin-related UI, even without any data? Considering that all of the routes which can return sensitive data are protected by JWT authorization, if a user access any pages or parts of your UI which require data, they would trigger a request to retrieve it, which would probably return a 401 (Unauthorized) HTTP status, or similar. A common front-end practice in these situations is to erase client user data, and redirect to a login page.
So, a typical flow would be:
User inserts a fake access token into their storage
User opens an admin page/ui which uses sensitive data in any way (showing, using for any internal logic, etc)
Web app does a request to the API requesting data
API returns a response which will be interpreted as an authorization error
Web app receive the API response, erase user access token and redirect them to its login page
In most cases, this entire flow will happen fast enough to block your user to further interact and explore your web app.
Would be better if you provide more information about your scenario, so anyone could understand if your worries are something that needs to be considered and truly solved. However, in most cases, the behavior above is accepted.

How to verify signed cookies are valid on the front-end?

I'm working on a React application. I am defining user roles and restricting access to components based on the permissions level of the role. I am looking in to using signed cookies to set the permissions from a php backend. When I determine whether the application should render a component based on the data in the cookie, how do I verify that the roles in the cookie have not been redefined by the user without sending the cookie to the backend?
That's not the right approach, in my opinion. The components should be free to load - if there's something built-in to a component that an un-authenticated user shouldn't be able to see, there's nothing stopping someone from going into the source and discovering it themselves.
You have to take a different approach for front-end applications - all the components and UI are public. When the component fetches information from the server to display to the user, the server will still do the session authentication and respond with a 4xx (401 would be a good place to start) and the component would handle that response appropriately.
If modifying the role in the cookie would allow the user to gain more rights, then the solution is not to check the validity of the cookie on the client side. The user could also modify the client side script to circumvent/skip the integrity check of the cookies, and you would have the same problem as before.
The only correct solution is, that the user won't get those informations/scripts at the first place. So you need to check on the server side what informations are allowed to be send to the client, only send the data the user is allowed to see, and verify all actions the user sends to the server on the server side before you execute them.

How do I pass a token when calling a website

I've been reading up on token based authentication for a project that's part of my trainee-ship. My task is to implement some sort of user authentication and we've settled on token based authentication.
Now I get the basic principles, like passing the token in the xhr header for xhr requests. But I do not understand how you would pass the token on an initial page call.
Let's say we're working on a single page application with a navigation bar that has a login button for users that are not currently logged in, and a profile button for users that are logged in.
Seeing as that navigation bar is delivered on the initial call of the website, how do I know how to serve the right button to the user? From what I can gather I can pretty much only authenticate on xhr.
Do I have a misunderstanding about token based authentication?
A little clarification:
Assume a User already is logged in and has received a token from the Server.
He then closes the Tab and later goes to my app again.
At this point, server-side I do not know the user, as I could not have sent the token at the initial request.
A coworker suggested using AngularJS' onload to send the token after the initial page load to verify and get my JSON data from the server, which is then used to create the app with Angular
Also the point of the project is to not use an existing library like JWT, so I can actually grasp the concept and the inner workings of such mechanisms.

ASP.NET Forms Authentication with per session/page API token

Let me first start by saying that I realize that this is very similar to many other questions about service access control but I can't seem to find one response that is relevant on all of the points below, so I am asking (possibly) again.
Some background:
I am building a web application with .NET that is protected by a custom forms authentication implementation. This same app (within the same domain) needs to leverage several REST services related to data management from within JavaScript/jQuery as many of the app's functions are not well suited to post back use in the forms.
I am trying to determine the most secure way to implement access control for the REST service based on the authentication done server side when the app was first accessed.
Here is an example use case for what I am describing:
user logs into asp.net site using forms authentication and upon successful authentication the user is taken to the landing page of the application
the user chooses to access a page at ~/Users.aspx from a link on the landing page, which forms auth allows based on the cookie created by the authentication in step 1
users.aspx loads some basic HTML elements, like an empty table and a hidden field that contains a token (GUID) generated at page load. The token in the hidden field is used by JavaScript to access a REST service that retrieves data to populate the table. The token is stored in a database with a pre-defined expiration.
when the REST service is called with the token it is checked for expiration and used to determine the user making the call and provide authorization to the data being accessed from the database, if the user is authorized to access/update the data the service performs the requested service operation, extends the expiration on the token, and returns a response.
I know that the token would be visible to someone sniffing the request/response on the network unless SSL is used to encrypt the transmission, so SSL is used to counter this.
My question is:
Are there other attacks that the service would be vulnerable to?
is there a better way to handle authorization and user identification for the REST service based on the server side login other than a statically assigned token for the service? It seems to me that the statically assigned user token would be less secure since it would give endless access to the service if it were obtained by a malicious user.
assuming the answer to #2 is no, is there a better way to transmit the token to the client and store it there for the life of the page use knowing that it needs to be accessible from JavaScript/jQuery?

Categories