I find myself in a bit of a dilemma. I am preparing to push code out to a test server (out in the wilds of the Internet) which handles user registration and authentication (using Express + Passport) for acceptance testing.
However, I would like to be able to restrict access to the test server to those users who will be performing testing. I know node does not support an .htpasswd file mechanism but looking for another way to restrict users from accessing the server even before the application authentication process begins.
All thoughts welcome!
You can restrict via IP address in your application, or the server's firewall. If you have a reverse proxy like nginx in front of node, then you can set it up to require basic authentication via an htpasswd-like file.
Related
I'm new to whole authentication/authorization part in web development. Specifically JWT. So I came across a medium post explaining the fundamentals of JWT. There was a diagram which showed how the web server and authentication server had no direct communication, AFTER a JWT token had been issued by the authentication server.
So, my 3 questions are:
What's the difference between the authentication server and the web server?
Is the authentication server, the database server?
And, since you are going to take user data(e.g password/username) from the
client(browser/user), to which server do you write the code to? authentication or web?
Because NodeJS/Express allows you to write the app server code right?
1 - An auth server is usually part of a microservice architecture, if you do not have to scale you can have a simple authentification middleware in your web server.
2 - The auth server is a server usually part of a microservice architecture which role is to authentificate requests and act as a gateway to the rest of the microservices.
3 - Depends if you want to scale or not. If you want to separate auth and the rest of the apis, there are multiple ways to scale.
Hope it helps =)
What's the difference between the authentication server and the web server?
These are two separate servers. Two different programs, potentially running on two (or more) different machines. With different purposes and responsibilities.
Is the authentication server, the database server?
No. For all you know the auth server may not use db at all. For example it can store all the data directly in files, or even in memory. Although, in practice there will be some db behind it. Auth server is just a server with a special purpose: user authentication (as the name suggests).
And, since you are going to take user data(e.g password/username) from the client(browser/user), to which server do you write the code to? authentication or web? Because NodeJS/Express allows you to write the app server code right?
Write code? Both? Depends on whether you implement the auth server by yourself or not. I'm not sure I get that question.
The point is that user credentials should be send to the auth server and the auth server is responsible for validation, secure storage and token issuing. So that other servers (in particular the one you call "web") don't have to worry about it.
I was wondering if it is possible to secure an expressjs RESTful API that only a react native app and react website could access.
For exemple my server is running on port 8000, my react native app is on port 3000 and my website on port 5000. I want the server to listen only to requests coming from these ports.
Let's say I have a POST route to mydomain.com/signup I don't want users to make that post request using external websites or tools like Postman.
What would be the best way to ensure my mobile app and Web site are the only ones allowed to access my RESTful routes.
First off, you are a bit mistaken about how a request to your API works. When your react app on port 3000 makes a request to your server on port 8000, it's just a random incoming request. It doesn't "come" from port 3000. In fact, the incoming port number with be some randomly generated port with 5 or 6 digits. Outbound ports are dynamically generated by the TCP system and you can't tell what "app" it came from.
Second off, your RESTful API server is just a server on the internet. Anyone can make a request to it. Using cross origin protections, you can provide some limits about what can be done from browser Javascript (only allowing requests from your particular domain's web pages), but other requests (not from a browser) cannot be blocked this way.
So, any code jockey using any tool other than a browser can write code to your API. What someone like Google does is they require you to either have an APIKey that they issued to you or they require some login credentials (often a cookie from a previous end-user login) that identifies the user making the request as a permitted user using their system. Even with these tools, this just means that a permitted user is accessing the API, it does not mean that only your app is accessing the API. And, in fact, you can't really prevent that.
So, what most people do is they require a login or APIKey credential and they track the type of use of the API. If the use of the API seems appropriate (particularly the types and frequency of requests), then that use is permitted. If the use of the API does not seem appropriate (often too many requests over some period of time), then that particular credential or user may be blocked from accessing the service either temporarily or permanently.
Let's say I have a POST route to mydomain.com/signup I don't want users to make that post request using external websites or tools like Postman.
You cannot effectively do this. There are obstacles you can erect to make it more difficult like putting an expiring token in your web page and having your own use of the API include the token and then detecting if its a valid token, but a determined hacker will just scrape the token from the web page and still access your API using it from whatever programming tool they want.
What would be the best way to ensure my mobile app and Web site are the only ones allowed to access my RESTful routes.
You can't. Your API is on the web. Anyone with whatever credentials you require can access it.
I'm considering using Firebase with my Electron App. Specifically I'd like to begin by using Firebase Authentication to sign users in to my app. I've done tons of research regarding the subject thus far, and my biggest concern remains that the domain I'd require for an authorized redirect would need to be localhost (Please correct me if I'm wrong). The Firebase interface sets localhost as an allowed domain by default, I assume just for developer testing, not for a live production environment (Again, please correct me if I'm wrong). The image below is the section of the Firebase Authentication interface that I'm referring to, for setting up authorized domains.
My question is this, in order to distribute an Electron application with access to Firebase, do I have to have the localhost domain authorized? As well, if I do have the localhost domain authorized, is this secure, in the context of couldn't malicious users set up their own localhost and redirect to an unintended page, giving them the ability to freely add data to Firebase databases?
If there's an alternate, more secure option than authorizing the localhost, what are my options?
I've read in plenty of places that the bulk of Firebase security comes in the form of setting applicable rules on who can read and write to the database. Namely this post gives some good oversight on the topic. But I'm a firm believer that if there are extra security measures that can be taken, then always take them, so long as they don't diminish the quality of the application.
Am I being too paranoid, or is this the right approach? Thanks in advance! Any advice or guidance is appreciated.
I see many questions in your post, but I'll answer these two:
My question is this, in order to distribute an Electron application
with access to Firebase, do I have to have the localhost domain
authorized?
That's not something implied by Firebase. Having the localhost
domain authorized is just for testing purposes when you're running
your app locally before deploying to another domain.
If I do have the localhost domain authorized, is this secure, in the
context of couldn't malicious users set up their own localhost and
redirect to an unintended page, giving them the ability to freely add
data to Firebase databases?
Yes, it is secure. You said you haven't started with Firebase yet,
but when you do, you'll find out that you need to download the service credentials
to be able to use the SDK in your app. Only you have access to these credentials. That's why other users can't setup their own localhost and access your authentication system.
I want to extend IdentityServer 3 with a 'admin' part where users can manage things like users, clients, etc. This part should be secured by the same ID server implementation (same app in IIS). Do I have to build a separate app or can I extend the same ID server solution? How do I configure the OWIN start up then? When I have
app.Map("/Identity"....)
how do I add:
app.UseOpenIdConnectAuthentication
This results in an 'external' login provider, but that is not what I want. I also tried to add:
app.Map("/admin", config => config.UseOpenIdConnectAuthentiaction())
But that does not work as well, so:
How to have ID server and a client combined in one Solution?
Please help.
Have a look at IdentityManager provided by developers of IdentityServer. This will get you up & running very quickly.
Security Model
The security model can be configured to only allow users running on the same machine or can be configured to use any Katana based authentication middleware to authenticate users.
Hosting Options
IdentityManager is hosted as OWIN middleware. It can be configured with the UseIdentityManager extension method for Katana
This is how you "Get started"
I want users, when they are in the workplace (e.g. on the LAN), to authenticate themselves with their regular username and password. Auto-login is disabled.
However - logging in from outside the LAN should trigger a 2-level authentication (like SMS, mail or similar). How can we get information about the users network when they try to log in to the application from outside the LAN?
NB - it does not matter if you have AD user and pwd. If you are on the outside you have to trigger the 2 level auth.
NB2 - we do not want any client-side scripts running, so this must be something coming with the initial request
Technology: IIS 7, ISA 2006, .Net 4, MS Sql 2008 server.
Question also asked here: https://serverfault.com/questions/354183/what-2-level-authentication-mechanism-is-available-that-can-differentiate-if-the
Information why ISA server remove the information I need: http://www.redline-software.com/eng/support/articles/isaserver/security/x-forwarded-isa-track.php
If it's reasonable, don't expose your web server to anything outside of your LAN -- require VPN access.
If that isn't reasonable, you should be able to use the REMOTE_ADDR variable to determine the source of the request. Whitelist your LAN as single-factor and require everything else to be multi-factor. Depending on the scenario, the server variables will be similar to either
Context.Request.ServerVariables ["REMOTE_ADDR"]
or
Request.UserHostAddress()
If you have a proxy in the way, make the proxy tag the originating IP source in the headers and read the request headers to determine the external IP.