When a Glide app is published using a custom domain, provide an option to make that custom domain the only supported user authentication entry point by redirecting or blocking authentication through the underlying Glide-hosted URL.
Why this matters
Glide Enterprise authentication is an excellent solution for organisations building applications for their own workforce.
However, many Glide developers are building commercial multi-tenant SaaS platforms where each customer has its own identity, security and governance requirements. In these deployments, the Glide developer becomes the software provider, while each organisation becomes the customer.
These organisations often want to enforce their own authentication pathway (Microsoft Entra ID, Cloudflare Access, Okta, Conditional Access, VPNs, managed devices, etc.) before users reach the application.
Today this is not possible because the underlying glide.page / glideapp.io endpoint remains a valid authentication entry point. As a result, customers cannot make their chosen custom domain the authoritative access path for their users.
This limits the value of Custom Domains beyond branding and prevents customers from fully leveraging the security technologies they already own.
Requested Enhancement
Add an optional setting:
Enforce Custom Domain Access
When enabled:
- End users may authenticate only through the configured custom domain.
- Authentication requests to the underlying Glide-hosted URL are redirected to the configured custom domain or prevented from authenticating.
- Existing editor, builder and development workflows remain unchanged.
Benefits
This enhancement would:
- Increase the value of Custom Domains for all Glide customers.
- Enable Glide developers to build enterprise-ready multi-tenant SaaS solutions without requiring Glide to implement multi-tenant identity federation.
- Allow organisations to leverage existing identity and security infrastructure such as Microsoft Entra ID, Cloudflare Access, Okta and Conditional Access.
- Improve security and governance for organisations of all sizes.
- Strengthen Glide’s suitability for business, government and not-for-profit deployments.
- Remove a common concern raised during IT security reviews.
This feature does not require Glide to build MFA, Zero Trust or enterprise identity integration. It simply allows the customer’s chosen custom domain to become the authoritative authentication entry point, enabling organisations to apply the security technologies they already own.
As a Glide developer building a commercial SaaS platform, this is the single biggest limitation I have encountered during customer IT security reviews. Solving it would make Glide a significantly more compelling platform for developers delivering business-critical applications to enterprise and government customers.
Love to hear thoughts from others on this topic?