I have a question regarding SSO and custom domains that has been bothering us since a few months.
We have the following setup in our company:
Okta tenant containing a custom domain and used for most applications, which is not under our teams direct control: identity[dot]company[dot]com
Single Page Application (SPA), hosted on myapp[dot]com, using PKCE flow for connecting to a backend. Backend is protected by the above identity[dot]company[dot]com. The SPA is under our teams control but the backend is used across different units, so we cannot change any IDP/ redirect setup there. Current login process redirect to identity[dot]company[dot]com and requires users to login with email + password.
We now want to add a custom branding when users log in to myapp[dot]com and also protect our frontend assets (currently anybody could download our SPA assets). We are not allowed to change the identity[dot]company[dot]com branding as it is used for a lot of other internal applications.
Idea:
Add an Okta authentication in front of myapp[dot]com (we configure this in Cloudflare Zero Trust). When users login to myapp[dot]com, they get redirected to myapp.identity[dot]company[dot]com and authenticate (which has the custom branding for myapp), and they get a session, which is tied to myapp.identity[dot]company[dot]com
Problem:
Users now need to login twice, once for the first Okta domain (myapp[dot]identity[dot]company[dot]com) that is there for the branding and protection of frontend assets, and second time for the backend, which is not in our control and uses identity[dot]company[dot]com.
Is there a way to achieve SSO in the same Okta tenant with 2 different Okta domains (as we want to have a different branding)? Would appreciate any suggestions or solution!
I am afraid I am finding this difficult to follow, so some facts/questions:
Your Okta tenant is controlled by another team, which is actually quite typical.
Is the back-end access controlled with an access token issued by this Okta tenant?
You talk about protecting assets; the SPA will be loaded before the user is authenticated. Generally the SPA will be a bundle with the assets, so it can’t be those. What types of assets are you trying to protect?
I have to ask: workforce or customer identity? Or a mix? It happens…
Hi @jmussman
Thanks for taking your time and looking at my post.
Let me try to answers your questions and explain a bit in more detail. I am not an expert on all of the below topics, but I will try to provide as much information as possible.
Yes, this is correct.
The backend we are using is a SAS service, which is integrated with Okta via SAML. It is a company wide platform that also has its own UI. Users can therefore either a) directly login to the backend/ SAS service, or b) via our SPA React App, which queries APIs of the SAS service. Both require Okta authentication. Once authenticated, the session id on Okta identity domain is set, and the backend also sets a BACKEND_TOKEN cookie on the domain (which is used for authentication to the backend).
Internal users directly login to the SAS application (they see the company branding, this is fine). External users go via our SPA, they should see another branding.
Our company has the policy that we need to protect all endpoints via Cloudflare, which normally also involves adding an IDP in front of the frontend URL. So when accessing the frontend, Cloudflare would automatically route to Okta and an overall session is managed with a Cloudflare cookie. Our SPA assets are just purely Javascript files, nothing else than that. Current setup:
Users access SPA and need to authenticate to Okta once the SPA initiates a connection to the backend. They see the internal company branding, since the SAS solution has it’s own integration with Okta and is also used internally. We want to change that branding, but not for the entire SAS application, just for the use case when users are logging in via our SPA application. Our idea/ target:
Add Okta IDP in Cloudflare in front of our SPA domain, so users authenticate before even accessing our SPA. This would be a different Okta application but within the same tenant. If we do this, the problem is that users need to authenticate a second time once the SPA initiates requests to the backend, as these sessions are on a different domain.
I am not 100% sure on that, but I am quite certain we use both, however, our main user base for this use case is external and therefore customer identity. But I can confirm this with our team.
Well, that took some thought. I think I followed it. You can have multiple custom domains pointing to the same branding, but you seem to need the opposite of that; multiple custom brands for one domain name. If there are different domain names involved Okta is always going to set the session cookie for the one used to call the /authorization endpoint.
This would be my suggestion:
If you can, use a generic name for the custom domain so that folks landing on it from different places don’t get confused by the URL for the authorization server.
Handle the branding in the custom page for the login widget on the Okta side. I have done this before. You can pass additional attributes you in the query string for the authorization request and they will be accessible to JavaScript on that page. You don’t have to touch the other application, just add it to the query string for the SPA. So, you can change the images, fudge the CSS, do whatever you want on the login page depending on what the application passed.
That way the cookie applies no matter who sent you to the IdP.
Thanks for the suggestion @jmussman! I work together with @simon1
By any chance, could you share an example of the Okta login widget code with us where you have achieved that dynamic customization within the same brand?
I created a new simplified example and put it at GitHub - jmussman/okta-pyrates-multibrand. This example works out of the box against an existing Okta tenant (pid.pyrates.live) to demonstrate. The readme file should explain everything. The custom login page source to paste into an Okta tenant is included in the repo, so it has both sides of the equation. Post back here if you have any questions, because other folks may be following this thread
Hi @jmussman
Thanks a lot for sharing the very detailed example and description. I will follow up with @tobiwunder and let you know in case there are any open questions.
I will let you know the outcome.
