There are a couple of ways to achieve this, and some complications related to the use of session cookies on Okta’s side to track whether or not the user currently has an active session.
With an embedded/self-hosted login page, you will need to determine if the user is already logged in to see if you can request tokens for them immediately, without needing to prompt them for their username and password. In short, here are your main options:
When the user hits the login page, call getWithoutPrompt. If the user is already logged into Okta AND your application is able to access the Okta session cookie, you will immediately get tokens back without having to redirect or re-auth the user. If it fails to get tokens or an error is returned, show the widget instead.
Downside: Browsers that block third party cookies can cause issues for this approach, particularly regarding Safari 13+ and Chrome Incognito’s default settings that can result in the user session in Okta not being found from the domain your application is hosted on. If you want to go this route, you can mitigate this by 1) configuring a custom domain for your org and 2) hosting your application on the same domain.
Option 2: Redirect to Okta to check if the user has an existing session. If there is no way for your application to determine if the user has an active session in the browser, and are thus able to get tokens without needing to provide their username/password again (third party cookie check), you will need to either prompt the user for their password again OR redirect them to Okta to get the tokens with getWithRedirect. This is not dissimilar from using getWithoutPrompt, but will involve a redirect to Okta to request tokens/access. Provided they do still have an active session in Okta, they will immediately be redirected back to your application with their authorization_code/tokens without needing to sign in again.