I have a public web API for a SaaS. We do not have user accounts for the users except for the admin, simply because the users who are using the system are often non-permanent workers or staff.
Instead we have a client/customer number and a PIN which is used to authenticate and setup the browser client. The authenticated JWT is stored in the browser like any other access token and is sent back to the server together with every API request. This works fine, although we do understand that a malicious actor could potentially extract this JWT and use it to illicitly authenticate as well.
Now we want to add two extra layers of security: IP whitelist and trusted devices.
First we have introduced an IP whitelist. This is straight-forward, we simply check the remote IP against a whitelist created by the admin which is bound to the client number.
Now the problem is with the trusted list of devices. For each client number, there should be a way to trust a device for that specific client number. So the client/customer should be able to use the web API only on the devices it has in the office. The ideal scenario would be that the admin can issue a "trusted device" certificate with a digital signature which sign something like "client number+year+client pin". Then the local manager individual needs to import this certificate/secret manually on the device that should be trusted.
Then for each request our web client app (via javascript) also sends this signature with each request in a HTTP header. I understand this could potentially be spoofed as well but together with the IP whitelist we assess and believe it should be secure enough for this application.
The problem is now, how to implement that? As far as I understand:
I cannot store such a secret in the browser because it might be cleared.
I cannot read the filesystem with javascript. Store the secret in a text file?
I cannot access the device certificate store.
How can I manage (import, store and read from javascript) this digital signature/certificate/secret in the client device? The web client can be anything from a iPad and Android phone to a Windows, Linux, iOS desktop. All web calls are done with SSL. We are not running any native app on the client device, only browser.
Related
I'm using Google Firebase, and unfortunately, Google Firebase put some countries under sanctions which means they must use a proxy (or VPN) to access the website.
Is there any way I can set a proxy setting for each client request that they can freely access Firebase without a VPN?
I know there are options for Node.js, but I'm looking for a web browser solution. Firefox has this proxy settings, and Google Chrome also has some options for extension developers, but I need a solution that works just in a web page, and it means when a user comes to my website, he/she does not need to set a proxy to access Firebase.
Example: when a user comes to my website from (for example) Syria or Sudan, they don't need to set VPN for their browser, because I have done some proxy configuration in my website
Short answer: You can't do it website-only.
Longer answer / explanation:
I know there are options for Node.js,
Good... that could work. Deploy your own Node.js server on Heroku or the like, which proxies requests to Firebase.
but I'm looking for a web browser solution. Firefox has this proxy settings, and Google Chrome also has some options for extension developers, but
This could work too, but as I'm sure you've considered... that would rely on the end-users installing those extensions before attempting to visit your site.
I need a solution that works just in a web page,
Nope. Not possible. The Google servers will not respond to any request coming from a sanctioned country. If a request comes from a disallowed country, the Firebase servers won't respond with your website - instead they respond with a 403. Firebase won't send the website. Your website won't be sent to the client. It doesn't matter what your website contains, it will never be sent to those end users in the first place.
Even if you host the site elsewhere, and just use the Firebase database, it still won't work - for the same reasons. When the Firebase servers receive the request from a browser running in a sanctioned country, they respond with 403.
The question then becomes: How to make the request appear to come from outside the sanctioned country, from the website only?
You can't, not when you only control the website itself. That part of the request/response cycle is, for end-user protection purposes, handled by the browser. Browsers do not expose that functionality to webpages.
If you want to handle everything for your users, without them needing a VPN (desktop, or browser), your only choice will be to send the request to a different non-Google server (such as a Node.js server you host on Heroku or the like), which then makes the request to Firebase on their behalf, gets the response, and responds back to the client. That way, to the Firebase servers, it looks like the request is coming from X* location.
*X: Where ever the Heroku server is running.
I am creating a desktop application that using Spotify's oauth api. I am using the implicit grant flow described here: https://developer.spotify.com/web-api/authorization-guide/#implicit_grant_flow
My idea is to have an "Authenticate" button, that you click and it opens your browser. You login/approve the connection with Spotify. Then it sends you to a redirect url.
I want to set this redirect url to 127.0.0.1:58212 or some port on the loopback device.
My question is, should I use https for this?
I am leaning towards yes. One because the access token needs to be secure, and I believe other users on the system could potentially read the message when it is sent, and two because in the time it took the user to log in, someone could have taken over the port.
So I want SSL for encryption of the message, and I want to ensure I am actually talking to my app.
How do I generate certificates in this situation? I think each instance of the application needs to have its own certificate, and I need to somehow inform the computer to trust that certificate during the lifetime of the application.
I could also generate the certificate during installation, and do some step during installation that makes the system trust that certificate.
Am I thinking about this the correct way, or am I going about this all wrong?
I am using electron and express in JavaScript to write my application.
Thanks for any advice.
The best way to securely use Oauth with installed applications such as desktop applications is to use the Oauth 2 flow for installed applications. But this option would have to be implemented by the service provider. Google provides for this option.
https://developers.google.com/api-client-library/python/auth/installed-app
Unfortunately, many services do not implement OAuth2.
To use Oauth 1.0 with installed applications, instead of returning to a callback_url, the service provider displays the auth code to the user which the user can then copy and paste to the desktop application. Check out Trello Ouath integration which allows for this.
The Web Api flow that you are trying to achieve will not work in the case of desktop apps. The redirect uri 127.0.0.1:port is your local uri. The service provider will need, at the very least, your public ip to redirect the flow back to your system.
AFAIK, for a Desktop or a native app it is much better to implement the Oauth authorization code flow. The implicit grant is intended to be used on a device browser and not on a Web View.
If your app uses a Web Service to connect, your Web Service needs a redirect URL that uses https. Luckily most hosting platforms like Heroku provide this to you for free (otherwise you need to buy an SSL certificate which might be a lot of work).
On the authorization code flow, a token doesn't need to see the client, it is all stored in the backend.
Most services allow you to test on localhost with http.
I wrote a tutorial that could give you some guidance on the flow.
My company is looking at using card based certificates (like CACs) for authentication on a web site; instead of the user entering a username and password this information would be extracted from the certificate. How does one go about programming the front end to pass the certificate on to the webserver? I've been looking for specific directions but wind up with everything but that. The over all idea is to hook into something like an LDAP for authentication eventually, but the browser part is completely eluding me.
You don't really have to do much in the way of the client side stuff. For a website, the browser handles it for you. You just have to setup your server to require a client certificate and the browser will handle it. Under Apache, after setting up the SSL certificate, this is as simple as setting SSLVerifyClient required (manual) in the apache configuration. Your site will then require a client certificate for access. You can also set SSLVerifyClient to optional which allows someone to click "Cancel" when prompted to select a certificate and the site will still load, but is missing the environment variables (see below).
If you are using smart cards, you might need a driver for the smart card reader to prompt the user for a pin to query the card, but it isn't something you need to handle. In my experience (with CAC cards), both Internet Explorer and Firefox use a third party software (we use ActiveIdentity) to ask for the user's pin (Firefox needs to be setup to use a "Security Device", but it is simple) and Chrome already has built in support for the smart cards without needing a separate program. It is also possible to install the certificate in the browser, but I haven't worked with that.
As for validating the user, in Apache, once the SSL handshake stuff has been completed by the browser and server, in PHP there are several environment variables that are available (you can see them on a phpinfo() page or if you print_r($_SERVER). They are all SSL_* and include stuff like the domain or common name). This can differ based on what information was supplied from the client. We just found one that held a unique id for the card $_SERVER['SSL_CLIENT_S_DN_CN'] and store that with each account. Then we can use that id to query for the account for creating a validated user session.
SSL client certificates are presented in the SSL handshake, which is done in the lower layers and is therefore transparent to the frontend (browser handles it internally). The web server needs to be configured to accept or require the client certificates so they are requested in the SSL handshake.
The client certificate is then validated by the web server and you can then access the client's identity typically via some API, depending on the server/platform.
EDIT:
Here's a guide for nginx/PHP: http://nategood.com/client-side-certificate-authentication-in-ngi
I have exposed the functionality over REST services, which only authenticated user can access. My clients are JavaScript based code running on browser and Android clients.
Code is using google+ based authentication ( for both JavaScript and Android). Now with browser client it is quite easy. As REST server can determine easily with passed access token, whether browser client is already authenticated or not.
However for android client; how REST server would know, that it is already authenticated. Is there any way to get the access code in android once user as has signed it. JavaScript client get access token, is there any token in case of android which can be used.
Yes I can implement oAuth (https://developers.google.com/accounts/docs/OAuth2UserAgent) for android client without going with google+ sign-in directly. That would solve the problem, just wanted to check whether I can do without. Appreciate any help with this..
I want to authenticate users on a web application. The users are already logged into their Windows Network.
Notice, this is NOT Internet Information Server. I have a Java Application Server on the other side.
Is there a way using Javascript or something, so that a Windows Authentication can be taken, then sent to the server, and on the server, that token being validated (assuming the server is on the same network).
I have found that you can convert a token into a Windows Principal
So I need the Client part. A way to send that token to the server.
Any ideas?
If you setup your Java web application to support NTLM authentication, e.g. by using the HttpServletFilter from the Samba Java library, this should work without implementing any client side JavaScript.
Depending on which browser the client is using, you may however have to configure the browser to enable NTLM authentication against you server. If I'm not wrong, IE is by default configured to allow transparent NTLM authentication against servers on the local network, but in Firefox, you have to enable NTLM for each specific server address.