I have an AngularJs application that consumes an API. I made this API with StrongLoop
What I want:
Be able to consume the API via AngularJs Controllers.
Not Expose the API endpoints to the user.
Now I was thinking I would somehow be able to do this with Node, where I query a local site URL with AngularJS and have Node process the routing and authentication token, but what stops the user from just using my local URL to get the results?
I want my website to consume the API, but not provide results to the user if they navigate to it themselves
That's the thing, on a HTTP level, there is no difference between the two.
Now you may implement an authentication and authorization system in place. Authentication identifies the client/user, and authorization decides whether a given user can perform a given action or not.
To implement the above, please refer to StrongLoop's Authentication, authorization, and permissions
Public APIs
If the API accessible to a AngularJS controller (a web client), just assume that it is accessible by the user by "putting the API URL in the browser". There's no way around this, both are valid clients to your API.
If you need to manage permissions, don't rely on the client side to prevent the user from doing it, but rely on the server side.
Permissions on the client side are just for good UX (User Experience, e.g. hide buttons to actions the user isn't allowed to perform).
The API itself doesn't trust any client.
Internal APIs
Once you have secured your public APIs, you may have internal APIs that only listen to requests from your node.js app to provide a specific service e.g.
public clients (ng-app, web browser) ---> public API (node.js) ----> internal API
Here you may have the internal API completely trust requests coming your node.js app, because the public API already deals with permissions and only calls the internal API with safe operations.
I think we need a bit more information on what exactly you're trying to restrict access to.
If you just want to limit the data exposed at the API to what's needed in the application the MVVM pattern might be a good candidate (I'm not familiar enough with StrongLoop to know if that's an option.)
Otherwise if you need to strictly restrict access to the StrongLoop API so only your server can access it, the Repository Pattern would be a good candidate for this.
Related
I am creating a public facing SPA web application using React js.
The backend for this application are the endpoints available under Azure APIM. I would like to restrict the access to these APIM endpoints in a way that they are only accessible from my react app.
As the react app will be rendered in the user's browser, I cannot have any IP restriction on my APIM backend inbound policy, as the application could be accessed from anywhere ( public facing). But if anyone gets access to the API url by inspecting the network traffic in the browser , my backend API's become vulnerable.
How can I restrict that APIM endpoints are only accessible from the react app ?
I have tried using CORS policy to allow my domain , but still tools like POSTMAN are able to access the endpoints.
The short answer is you cannot fully prevent people from hitting your public API endpoint on their own.
The longer answer is that you can put protections within your API config so that this isn't a concern. If all requests need a valid user authentication token, for instance, it doesn't matter if that valid request comes from your React UI or an errant user's terminal window. Check out some best practices on protecting your API endpoints, and it will hopefully answer your question.
You can't. At best you can obstruct the user by making it harder to replicate a proper request to your API. Ultimately there's no way to identify whether or not a request came from a browser or some other tool though.
It's up to you to construct the API in such a way that the user can't abuse it by limiting the user to only perform actions that they should be allowed to make. If you are concerned by a user overloading your API you can add a policy to APIM to apply rate limiting (e.g. by IP).
It not be possible to prevent attackers from inspecting HTTP traffic and the vulnerable calling endpoints.
You should implement authentication controls on API. Whenever a user opens a new session on you SPA, the API grants that user a token that is valid for a fixed amount of time (~30 mins). Ensure that the API checks if that token is valid for each request.
I have a react web application with a flask api (I used to use express). The product of this app is the data that it displays. I don't want other people to be able to take that data easily from calling the api.
I want to secure the api such that it can only be accessed by my react app and nothing else. How can I do that?
The only way to truly secure your API is by authenticating your app's user with something like Oauth2 and verify that credential on server-side with something like passport, and make the authorization expire with sessions. AND use SSL so none of that is easily visible through a protocol analyzer.
Sure, you can hard-code some sort of "secret key" with the app, but anyone who want it bad enough will read it off your app or sniff the packets through a packet logger until they find the key.
EDIT: Oh, and as a part of the authorization upon login, provide them with a uniquely generated "API-KEY" as part of identity, so you can validate them upon submission, and if they violate your trust, mark their API key invalid in the server so they can't use them any more.
First, if your client code and API server are running on different domains or ports, configure CORS on your API server to only honor requests that originate from the client code's domain. Second, authenticate legitimate users so that only authorized requests for data are honored. There are lots of 3rd-party libraries to help with authentication.
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'm struggling with the correct way to secure a multi-tenant Web API with Identity Server. Let me explain.
We have a multi-tenant Web API that serves a ASP.NET MVC application.
Each new customer is assigned a new TenantId.
A customer can have multiple subscriptions of the application. Its
the same as saying that the app manages multiple databases per
customer (that he can access from the same base URL).
Each user belongs to a single customer (tenant) and will have access
to all that customer's subscriptions.
The API is set in a way that every endpoint includes both the tenant id and the subscription id so it can know from which subscription/database it should get the data.:
<server>/tentantId/subscriptionId/(...)
Now imagine that I have another external app (say a console app), using the client credentials flow, that is trying to access some API resource "on behalf" of a customer, meaning that will use a specific tenantId/subscriptionId pair:
<server>/1000/1/products
Every time a call hits one of the API endpoints I need to validate that this specific client app can access that tenant/subscription.
It would make a lot of sense if the Identity Server could perform that check automatically as part of the authorization flow.
If we added some way for the customer to register (consent) a specific client app to access the Web API on it's subscriptions, may be we could also set the Identity Server to know that in the form of scopes or at least include that information in the claims so that we could perform the permission check by inspecting the token instead of calling an external component.
Is this even possible?
Should I try to use scopes? Claims?
Can anyone point me in the right direction?
Your question is confusing when you talk about multi-tenancy. Isn't an API multi-tenant by default? The way I see it, it's a resource that can be accessed by multiple users / clients.
If I understand correctly, all you want is to access the API through the MVC app on behalf of a user. In other words: a hybrid flow with API access.
Instead of putting the userid in the path, use the id from the sub claim. Which lets the API distinguish between calls on behalf of clients and calls on behalf of users.
The resource should take care of authorization. Depending on the type of authorization you can use claims. If a subscription needs to be checked then this should be done by the API, using the sub claim to distinguish the user.
Scopes on the other hand are meant to define the resource. With the scope "api1" I can access the Api1 resource (api). But it says nothing about authorization.
IdentityServer provides Authentication as a Service.
It is your apps' duty to provide the actual Authorization.
I am trying to implement Azure AD authentication in a SPA application.
I am using an OWIN Startup.cs file in the WEB API and ADAL.js file in the angularjs front end application. (as per most of the tutorials suggestion)
My application does not have WebAPI and UI hosted in different domains/port. Basically, the WebAPI is referenced in the UI application project. (So no need for enabling CORS).
Now I have registered the applications on the Azure AD separately.
i.e. ClientApp -> Reply URL: http://localhost:90/ and
WebAPI -> APPID SignOn URL: http://localhost:90/Api/V1/
I have configured the ADAL.js and also getting the login page when trying to access the application from the UI. Also, I am able to retrieve the id.token generated after logging through the URL redirection. Also have decorated the web api controllers with the [Authorize] attribute.
My main concern here is that, if I try to call the WebAPI directly using tools like postman, I am getting access denied/Unauthroized Access (401). Can someone pls explain how can I test on my local env. with this scenario?
My sample request is: http://localhost:93/Api/V1/User/Preference (GET)
I am adding the token in the Authroization property of the Headers in the web api call.
Also a side note, I don't think I require OWIN/Startup.cs file for securing the WebAPI. The way I tried is that I got the token value send through the headers and got the AudienceID using JwtSecurityToken and parsing the contents of the Authroization property. Is this approach right as per security or I should stick to the OWIN implementation.
All of the ADAL JS tutorials have the backend API and the UX hosted on the same domain and port, with no need for CORS. See for example https://azure.microsoft.com/en-us/resources/samples/active-directory-javascript-singlepageapp-dotnet-webapi/. Those samples demonstrate that you need only ONE Azure AD registration, as the JS layer is in effect the exact same app as the web API.
We do have some samples demonstrating how to call an external API as well, and those do require CORS- but only for the extra API. The logic for calling the app backend remains the same (just one Azure AD app registration, no need for CORS).Postman doesn't offer any opportunity to pop out UX, hence one strategy you can follow is to obtain the tokens you need beforehand.
The use of OWIN allows you to centralize the auth setup; if you add auth in the controller, you'll need to repeat that logic for every new controller you add. Also, maintaining the code will be harder as you might use API surface that requires code changes when you update the assemblies, while that's less likely to happen if you use the standard middleware setup