We are planning to implement an AngularJS web application communicating with Business components via REST service layer. The web app needs to offer authentication mechanism.
For example we are particularly concerned by the user authentication process since Angular code is practically available to the users on their clients.
And how can we reassure that the users are authenticated after the initial authentication process (in JSP/PHP we would use sessions)?
Could you please give us some pros. and cons?
Your right client side code is available, viewable, and editable thru standard browser developer tools. If your company does any type of security audits on your software you'll find that for security reasons processing is done on server side outside of the view of the client code. The companies I have worked for have taken the approach to trust nothing that is sent from the client side to the server.
On the server side the REST layer typically contains a authentication layer that will bubble back to the client when.
-invalid session
-incorrect permissions to make rest call
-invalid REST args
-prevents script jacking into text fields
-etc...
When working with angular or other client side only applications, I recommend using Token based authentication.
A demo application in Angularjs
Token Based Application
Angular JS, Web API Token Based Authentication
Related
Our application uses AngularJS and consumed Web API in the backend. This is only internal application and authentication used is 'Windows' mode only. We are using custom authorization(role-base) to limit the access/execution of the application web api methods.
My question is do we need to add ValidateAntiForgeryToken attribute for those web api action with HttpPost and HttpPut attribute? I never use this ValidateAntiForgeryToken before as I was only involved in internal web application (local intranet only). Please guide me when/how to use ValidateAntiForgeryToken.
ValidateAntiForgeryToken protects your users from malicious web apps that send a POST request to your web app unbeknownst to your user, known as CSRF. Still the request would succeed since it's coming from your user who actually has permission to do so.
This is irrespective of the actual authentication mechanism, and is in fact a higher risk for automatic single-sing on that you have with Windows authentication.
If your internal web app is worth the effort, a targeted attack could trick your users to visit the attacker's web site that in turn sends the POST request to your web app.
My take is that you should use ValidateAntiForgeryToken even in this situation as a defense-in-depth measure.
I am having difficulty understanding Hybrid flow with mobile application. I am using code id_token Hybrid flow provided by Identity Server 4 in .Net.
Here is my scenario.
All mobile request will go to backend server and backend server will forward request to different APIs on user behalf.
When user first time login
He will be redirected to identity server
A mobile web view will be opened
User will sign in using credentials
identity server will send Id Token and Access Code to Back end
Server
Back end Server will swap Access code for Id Token and Access Token
What token will be returned to mobile application to provide that user is valid. And is it responsibility of Back end server to get new access token without prompting user to re login until user sign out?
Is there any step wrong in above scenario ?
For mobile clients its recommended to use Authorisation code flow along with PKCE. Please read through these two answers to grasp some idea why its suggested Link-1 & Link-2.
Also, RFC8252 provide some best practices application for Native Apps (mobile clients are native apps.!). In that, it recommend not to use web-views.
here is a quote from RFC8252-overview
Previously, it was common for native apps to use embedded user-agents
(commonly implemented with web-views) for OAuth authorization
requests. That approach has many drawbacks, including the host app
being able to copy user credentials and cookies as well as the user
needing to authenticate from scratch in each app
By using web-view, you loose the true essence of OAuth 2.0. You client app get the ability to grasp end user credentials. So use the browser instead of web-view. (Please read more about embedded users agents from this link)
In your architecture, you could enable all of these, PKCE, Authorization code flow and usage of browser instead of web-view. But once the backed receives tokens, it should pass them to your client. That will be a challenge if you stick to this architecture.
But if you can make your mobile application to complete whole flow, you avoid that complexity. Once tokens are received, you may create a connection between backed server by validating tokens. Also, when tokens expire, mobile app will use refresh token to obtain new tokens.
I have been trying to determine a good strategy for authentication between a single WPF application of which calls to Web API services.
The client WPF app should be the only application to ever call the Web API.
I think I do have some unique requirements I must abide by. For example, The boss does not want to use ssl in any way; he is paranoid of users may having to deal with certificates.
Like I said, the client application is the only client using the Web API. The API just calls a list of stored procedures on a separate server.
Currently, we have a user membership database that does not align with any membership db standard, but we currently have over 200,000 members. One of the stored procedures currently authenticates the user with the membership db. The client application requires valid users to sign in to the application at start-up, however, we are wanting to secure all of the Web API requests sent from client to prevent non-valid requests being made to the server and so to prevent.
We are concerned about using the individual accounts or local authentication to essentially authenticate every web API request because of the added cost.
I have been thinking that what we are really needed to do is pretty much authenticate that it is our software client(WPF application) making the request and this authentication could open up all the controllers and actions for requests made by the client rather than the user. The user and its authentication is somewhat separate and is in place to prevent unauthorized users on a particular machines install of the application.
So you must have a valid user account to use the application.
Any suggestion would be great. I am just asking to get pointed in the right direction. I am really new to security so all suggestion will be valuable to me.
Thanks.
I'm start building a web application where the user needs to authenticate in order to get access to different modules.
I have been working with ASP.NET MVC in the past and it was quite easy using FormsAuthentication and Server Sessions so I don't have to do roundtrips to the database in order to get the user roles or any other user related data everytime I access a web method.
What I have been reading, AngularJS won't work that way so there won't be any Server Session, etc.. So...
In case I need to verify user identity every time I access a web method do I need to consume database or there is any good practice that I can learn of?
I know there are ways to store state data in client side but how that can affect the performance of a web application?
I have seen that when a user login to an application the best way is to send a Token to the client and then force AngularJS to send that Token everytime a web method is accessed... but what about sending to the client the user sessionId (from database) and then on every web method consumption sending that and then create a filter where you check that the sessionId exists in the database so the user identify is validated?
Appreciate any advice or recommendations.
Thanks.
My take on authentication is that you do not need to bring AngularJS into picture till the user is authenticated. You use simple login page and authenticate user and then redirect him to your app page that has Angularjs. Look at my old answer for more details How to handle authentication in Angular JS application
Let me try to address your concerns.
In case I need to verify user identity every time I access a web
method do I need to consume database or there is any good practice
that I can learn of?
Once you have been authenticated that part is taken care by server and browser cookies, you don't need to do anything. How standard MVC site works.
I know there are ways to store state data in client side but how that
can affect the performance of a web application?
Since AngularJS is a SPA, there is no page refresh. Data stored at $rootScope or using service are there till one refreshes the page. Performance would be better as there are less round trips involved.
I have seen that when a user login to an application the best way is
to send a Token to the client and then force AngularJS to send that
Token everytime a web method is accessed... but what about sending to
the client the user sessionId (from database) and then on every web
method consumption sending that and then create a filter where you
check that the sessionId exists in the database so the user identify
is validated?
This is standard form authentication, and transparent to developer, whatever was required to be done in traditional MVC app for authentication would work here. You don't have to worry about sessionids, tokens etc. To get users identity on the client, you can write a angularjs service with methods such as getUser to get the current logged in user. But i warn you that the authorization related decision should still be done on server.
I would like to create a new AngularJS, Web API Single page application. Does anyone have any examples that show how I can set up a user login screen that connects to a WEB API controller for a simple login (no need for google/facebook login etc) that uses ASP.NET Identity and without the need for user registration.
Also how can I handle showing a new view once the login has been completed. What I would like is to have a solution that does not show routing in the browser URL. So for example I would like to be able to switch from the login view and a couple of other different views without the url changing from www.abc.com.
In other words I would like to avoid showing www.abc.com/login, www.abc.com/screen1, www.abc.com/screen2
Any advice would be much appreciated.
So, instead of trying to find an example, I created one instead (link at the bottom). To explain how the functionality works, I want to go over a few things:
The new ASP.NET Identity system provides an OAuth 2.0 Bearer token implementation which can be used with clients that consume a Web API resource over HTTP. Since the authentication is not stored in a session cookie, the server is not responsible for maintaining the authentication state. The side-effect is that the consumer has to manage authenticating the server and managing the returned token. This is the system that Microsoft uses in the SPA template that it provides with VS 2013.
AngularJS makes no assumptions about authentication, so it's up to you how to authenticate.
AngularJS provides the $http service for querying remote HTTP-based services as well as $resource which is built on top of $http. Using Authorization headers with the Bearer token implementation above, you can combine both to provide authenticated access to server resources over HTTP. AngularJS allows you to set a 'default' Authorization header which it will use in every subsequent HTTP transaction.
With that in mind, the way I accomplished this is by creating a User service that handles all of the authentication details, including setting the HTTP Authorization header, between the Web API server and the SPA. Based on the authentication status of the user, you can hide certain UI elements in order to prevent navigation. However, if you also define the state as requiring authentication as a property of the resolve object for the state, a watcher set on the $stateChangeError event will capture the error and redirect the user to the login form. Upon proper authentication, it will then redirect the user to the state they were trying to navigate to.
In order to prevent authentication from being lost between browser sessions (since the client is responsible for maintaining the authentication token, and that token is maintained in memory), I also added the ability for the user to persist the authentication to a cookie. All of this is transparent to the user. For them, it is practically identical to traditional form-and-session based authentication.
I'm not sure why you want to prevent the user from seeing the routes, but I have coded it as such. I am in debt to Sedushi's Plunker example of how to use AngularUI Router to navigate in a stateful manner without using URLs. Still, I'm not sure I can personally recommend this for any application I would write on my own.
The full solution (both the WebAPI and the WebUI) is available with step-by-step instructions here.
Let me know about any specific part that is unclear, and I will try to make it more clear in the answer.
Refer the following blog for the demo of single page application (SPA) for ASP.NET Web API 2 and AngularJS, developed by the team at Marlabs.
http://weblogs.asp.net/shijuvarghese/archive/2014/01/25/demo-spa-app-for-asp-net-web-api-2-and-angularjs.aspx
The app is built with following technologies:
ASP.NET Web API 2
EF 6 Code First
AutoMapper
Autofac
Semantic UI
AngularJS 1.1.5
The application is published on github at https://github.com/MarlabsInc/webapi-angularjs-spa.
#DavidAntaramian gave a great example. But if you want a simple one, you can look to this HOL from Microsoft.
Their latest example on github uses .NET Core, but you can download release from October 2015.