On-Prem with PropelAuth Guide
Do you have a customer that wants to have their own isolated version of your app on their private cloud? This guide will cover the basics on how to get started with implementing PropelAuth for on-premise deployments, allowing you to maintain robust authentication while meeting your customers' security requirements.
Considerations
The first question to ask your customer is if their VPC (virtual private cloud) or on-prem deployments have the ability to make external requests to the public internet. This is important since your customers will need access to the hosted pages as well as make requests to your Auth URL to keep their access tokens up to date.
Isolating Your On-Prem Customers
While it's not always the case, chances are that customers who require on-prem deployments also require that their users are completely isolated from the rest of your user base. To achieve this, we recommend creating a new PropelAuth project by clicking the + symbol next to the project dropdown towards the top left of the PropelAuth Dashboard.
Verifying Your Customer's Domain
Creating another project also adds the benefit of verifying a domain in your customer's private cloud. For example, let's say your app is normally hosted on https://app.example-app.com
but your customer requires that it's hosted at http://example-app.acme-inc-private-cloud.com
.
By navigating to the Go Live page of your new project you can verify this domain (with the help of your customer to verify DNS settings), therefore creating a new Auth URL of http://auth.example-app.acme-inc-private-cloud.com
. This also helps with preventing third-party cookie issues.
What if they don't require an isolated environment?
Let's say that your customer does not require an isolated user base. This means that you can simply add the location of their on-prem version of your app as an Additional Frontend location.
That being said, there is a fundamental problem with supporting multiple domains in one PropelAuth project - cookies. More and more, browsers are blocking third-party cookies (cookies that are set by one domain on a different one) which can cause errors and infinite redirects within your application. There are three ways to solve this:
-
Using OAuth: OAuth makes it easy to support multiple domains in one project since each of your customer's domains can be added as a Redirect URI. The Redirect URI then exchanges a code for the user's access token, allowing the domain to set its own cookies. There are typically multiple OAuth2 libraries for whichever framework you're using, most of which are compatible with PropelAuth's OAuth2 support.
-
Instruct Your Customer to Allow Third-Party Cookies: Some browsers, such as Chrome, allow third-party cookies by default. Browsers that do not, such as Firefox and Safari, have settings that your customers can adjust to allow for third-party cookies. Warning your customer about the issue and instructing them how to avoid third-party cookie issues is another possible solution.
-
Creating a Separate Project: As covered above, this will allow you to verify your customer's domain to create a new Auth URL, therefore preventing third-party cookie issues.