Custom Login page with multiple backend servers

When using the Okta hosted login page the user experience works better vs the custom login page when there are multiple backend applications servers.

With custom login page, the user has to re-login if directed to a different server than the one they logged in at

Working correctly with Okta hosted login:
using this project

  1. After setting up yaml file with correct settings, start the application
  2. Open new Incognito window
  3. go to localhost:8080/profile, this is a secure page so you’re redirected to Okta to login
  4. login and you get the profile page.
  5. simulate user going to another backend server by shutting down the application and restarting it
  6. refresh the profile page in the web browser.
  7. the profile page displays normally

If you kill your internet connection after step 5 and you refresh the browser you’ll see that it makes a call to Okta because the local app doesn’t have the information from the user cookie to determine if this browser session is logged in, or at least that’s my simplified understanding of it.

With the Okta hosted login page, the user is not shown the login page again, the profile page just displays normally.

With the custom login page from this sample

Everything is the same as above but after you refresh your browser (step 6) the user is redirected to the custom login page.

Seems to me that if you use a custom login page in a production application and you have multiple backend servers, the users will be required to login every time they hit a new server.

Is there a workaround for this? I’d like to be able to use a custom login page

Hey @Vladimir !

Another option is to configure a custom domain:
And then configure an “Okta hosted” version of the widget/login page as needed.
(and this would work with any OAuth 2.0 client without any additional custom code)

Keep us posted!

Thanks, I’ll switch back to the Okta hosted one.
With the custom login, logout worked. What do I have to do to logout the user with the hosted one?

What type of logout are you looking for?

The custom login worked because it wasn’t an SSO session. The next version of Spring Security / Spring Boot (Spring Security 2.2) will support RP-initiated logout (which will allow for an “SSO Logout”), This is due out after Spring One in October. Until then you could try to use the milestone release (or wait, depending on your timeline)

NOTE: Logout does work, it just removes the applications session, the next time a user access a protected resource, a redirect to Okta will happen (where the user is still already logged in, so the user will be redirected back to your application, giving the appearance they are still logged in)

I’m able to log the user out by calling clear session.

All good now.

1 Like

I’m on AWS and i tried generating a SSL cert there from Certificate Manager but I’m not able to export it so I can enter the Certificate and Private key at Okto setup screen.
I tried generating one at but when I enter it at the Okta Custom URL Domain screen the error says
“The certificate must not be a Certificate Authority (CA) certificate” for the Cert and
“The private key length should be 2048 bits” for the key error.

At the Upload you TLS certificate “For detailed instructions see here”
Which has no info about certificates.

Is there some simple instructions somewhere I can follow to get this working?

I managed to stubble my way thru it and add a valid certificate.
Having other issue now Issues with custom domain

Can you give solution or adding TLS certificate?

Here’s what worked for me. I’m using letsencrypt as the cert provider and my site is on AWS.

Using an Ubuntu 18.04 server I installed certbot so that I can generate a certificate.

I tried using an AWS linux ami in place of Ubuntu but I could not install cerbot.

The command to install certbot is - sudo apt-get install certbot python-certbot-apache

Once that’s installed the command to generate the cert is

sudo certbot certonly --manual --preferred-challenges dns

To verify that you own the domain for this certificate letsencrypt will have you add a TXT record to your DNS record, in my case Route53.

Once this process is done you should have cert.pem, chain.pem, fullchain.pem and privkey.pem

Login to your Okta account and navigate to Settings -> Customizations. Note, this is in the “Classic UI”. I could not find this page in the Developer console.

Under “Custom URL Domain” choose Edit or whatever it says if you have not ever set this up.

You should be presented with a screen that has three multi line input boxes - Certificate, Private Key, and Certificate Chain.

In Ubuntu type cat cert.pem to get the text that goes in the Certificate entry. Do the same for privkey.pem which is the Private Key.

For the Certificate Chain, it says optional in the Okta UI but from what I’ve seen, this is required and won’t work without it.

Use the contents of your chain.pem for this entry.

That should be all you need to do. Seems like a took a little while for things to propagate and become valid so if you’re getting certificate errors in your browser I’d give it some time to see if it resolves it’s self.

The letsecrypt certs are only valid for three months so take notes cause you’ll end up having to do this again rather quickly.

good luck

1 Like