White label authentication that carries your product's name
White label authentication means your users sign in on pages that carry your product's name and address, not the name of the identity provider behind them. The Skycloak Platform is built for this: each tenant can serve sign-in from your own domain, send its sign-in emails from its own subdomain and issue tokens from that same address.
What white label authentication means in practice
When a user signs in to your product, they see a sign-in page, they may receive a sign-in email, and their browser receives tokens from an issuer address. In a white label setup, all three point back to your product rather than to the company that runs the sign-in service. The issuer is the address written into each token to say who created it, and your applications check it on every request. If any of these show a third party's name, users can reasonably wonder whether they are on the right site.
This matters most for products where trust is part of the sale, because a sign-in page on an unfamiliar domain looks like the start of a phishing attempt. It also matters for your support team, since users who are confused by an unknown name tend to open tickets or give up before they finish signing in. Keeping the same name from the first page to the last message removes that doubt. It also means you can change the provider behind the scenes later without your users seeing a new brand.
How the Skycloak Platform keeps sign-in under your name
Each environment you run, such as production, staging or development, is a tenant on the Platform with its own users, settings and sign-in address on skycloakid.com. The Platform is built so that you can add your own domain to a tenant, so your users sign in at an address under your product's domain instead. Tokens are then issued by that address, which means the issuer your applications trust is a name you control. Because the tenant is chosen only from the sign-in address, the domain also decides which users and settings apply.
Sign-in emails, such as verification messages, go out from the tenant's own subdomain rather than from a sender shared by every customer. That keeps the reputation of your messages separate from other tenants and gives your users a sender they recognise. Custom domains are on the Platform's plan along with the rest of this setup, and we only call a feature available once it has shipped. The look of the sign-in pages is a separate question, and a demo shows the branding options you can use today.
White label sign-in for platforms that serve businesses
If you sell your product to other businesses, each of those customers often wants its employees to sign in with the identity provider the company already uses. The Platform's plan includes organizations, which represent your business customers inside a tenant, each with its own roles. An organization can be connected to its own enterprise single sign-on over SAML, so that customer's employees sign in through their company's directory while still seeing your product's sign-in pages. Inbound SCIM provisioning from Microsoft Entra ID, Okta or any SCIM 2.0 directory is planned too, so accounts are created and removed as the customer's directory changes.
Groups in the customer's identity provider can be mapped to that organization's roles, so access follows the customer's own records. Removing a user from a group removes the matching role in that organization only and leaves their access to other organizations alone. This lets you offer each business customer a sign-in that feels like part of your product, while each customer keeps control of who in their company has access. Your team does not have to build that per-customer plumbing itself.
Frequently asked questions
Can my users sign in on my own domain?
The Platform is built for that. Custom domains are on its plan, so a tenant can serve its sign-in pages and issue its tokens from an address under your domain instead of the default sign-in address on skycloakid.com.
Who sends the sign-in emails?
Each tenant sends its sign-in emails from its own subdomain, rather than from one sender shared by every product on the Platform. That keeps your messages separate from other tenants' messages and gives your users the same sender every time.
See the Skycloak Platform for yourself
Book a demo and we will walk you through the Platform with your own sign-in flows in mind.