Securing a Web URL when called by a client application

Question

We are developing a single page Angular2/NodeJS app which will have a web based form for our users to fill and submit.We do not have any Web based application for our users to login to (so no SSO), but our users logs into our partner Apps, which can be a web application or mobile device each having its own authentication mechanism. Our partner apps basically calls our api to get various contents and show that in their UI. Now one of our content will have the link to the new form app that we are developing.

We want to secure the call to the Form app in such a way that the request can only be triggered from our partner apps and from no place else. The partner apps cannot stop the user from copying the url but we want to make sure that the request came in from our partner apps.

What is the best way to achieve this with minimal to no coding for our partners as we have no control over their development or release cycles. Few of the options we are evaluating

Option 1 :

Check the http header, Referer. https://en.wikipedia.org/wiki/HTTP_referer. This may not be the right solution as a) it can be easily spoofed (https://stackoverflow.com/questions/14854117/php-allow-access-to-specific-referrer-url-page-only) and b) The client can be a mobile app and decide to not send the header

Option 2 :

Another option would be our partners to pass a token as a hidden parameter. So assuming any non tech savvy user will not look into the page source to find what the token is. Ofcourse this may need some dev activity from our partners which we would like to avoid.

Are there any other elegant solution which we can try

Answer 1

You're trying to use your vendors as Single Sign On providers. That is absolutely possible... if they are willing to implement some federated identity protocol like OAuth, SAML, Kerberos, etc. This would involve substantial engineering work on their part, and probably substantial burecruatic work and legal liability since HIPAA is in play. (I don't know. I'm not your lawyer).

For the reasons you've listed, relying on the Referer header or a shared, unlimited-use, unaccountable secret is absolutely out of the question. Further, trusting a user simply because he was logged in at a trusted vendor is also out of the question. Your API needs to know who, specifically, is acting on it, and store/log that information. Your business may not care, but HIPAA does.

SSO/federated identity protocols are ways of generating, passing, and checking tokens like your Option 2 that are specific to the user, time window, etc. Don't invent your own. OAuth is probably the easiest to implement.

The simplest solution is to build user accounts into your NodeJS app. Users must be logged in (have session cookies) to get anywhere with the URL from your vendor. No federated identity problem.

Another fairly simple solution is to have your API and your vendors' backends communicate directly, with no end-user browser in the loop. HTTPS and a simple token in an HTTP header would be reasonable. Mutual TLS with client certificates is the gold standard. But this relies on the secrets staying in the backend. This would also mean any changes in the way you interact are code changes for your vendors.

The real solution is to implement an Identity Provider (farm it out to Microsoft Azure, AWS, or OneLogin, or hire consultants to do it inside your firewall) and integrate it with all your vendors and your API so that your users only have one account to deal with. Your existing vendors almost certainly don't want this role. SaaS folks might not want it because HIPAA, but probably one of them will be willing to execute a HIPAA Business Associate Agreement for the right price.