Login page should have Username first and then ask for Password in second step

[rajivranjan.kumar]

Hi,

In the Okta apps, there is a feature where Okta can redirect the user to a custom login page to perform the authentication. Is there any way in Okta that can help to achieve this for OIDC apps. The use case is, where Login page should ask first Username only and If the username is exists then go to second step and ask for Password and if password is also valid then redirect back to my application. And the another requirement is If Username is not exists then go to Registration page for signup.

Looking for your help…

Thanks.

[Ironhide]

You will need to make some API calls to achieve this goal.
Hosting a login portal yourself can be done with okta API calls, the widget makes it easy and it can listen on certain events. You can also override some of it’s behavior with javascript.

You can first show a simple form with just username, with this you should call the Okta users API https://developer.okta.com/docs/reference/api/users/ and see if you get a response with the provided user. If users exists, show password field, if not redirect to your registration page.

[rajivranjan.kumar]

Thanks @Ironhide for your quick response.
But I have to integrate OIDC authentication with many applications which are already developed into different-2 technologies. The requirement is to use this single custom login application for all the OIDC applications. Is this possible in Okta?

[tparikh]

Hello @rajivranjan.kumar
I am also having the same requirement.
Have you got the solution on this?
Thanks

[abole]

Hi @tparikh could you please describe the experience you’d like to achieve? We may then be able to provide some suggestions.

[tparikh]

@abole
We have standalone application (React + NodeJS) which uses embedded Okta SigIn Widget( with authorization code flow) to show Okta login UI

1. The use case is, where Login page should ask first Username only and If the username is exists then go to second step and ask for Password and if password is also valid then redirect back to my application.
2. We are using Custom Forgot password form instead of Okta provided form, after this step, I want that the user should automatically get Logged-In.
   For automatically Logged-In - we are using okta “/authn” call, which returns the session token but this authn call we are doing in Nodejs and problem is that how we set the session cookie in client browser so that user gets logged-In.

Thanks

[abole]

Hi @tparikh
For #1:
I don’t know of any default config settings you can apply to a custom hosted widget to do that. As you’re hosting, you can certainly make changes to your build of the widget to create that kind of experience.

In the Okta Identity Version there’s a new interaction flow you can use to build out the experience - that may be able to deliver what you’re aiming for.

With Okta classic, you can ask support to enable the factor sequencing early access feature. This works with Okta hosted login and displays the username first, then password on a separate second page.

If the username is exists then go to second step and ask for Password

You may want to be careful about user enumeration here. An experience like this can expose valid usernames in your app to bad guys.

For 2:
If you don’t mind not being fully openid, you could perhaps change your login flow to use the /authn api which gets you a sessionToken which you can swap for an access (and refresh) tokens if that’s what your app is using. This gets you an okta session in the browser.

[tparikh]

@abole
Thanks for the information.
For #1 - We are using embedded Custom Okta SignIn widget not a hosted one.
I got the Solution, If we pass “idpDiscovery” parameter as true then it give me the same experience “Username first and if user types an email then password field gets populated”
Let us know if its a correct way to achieve this.

For #2 - Sorry not able to get you on this. Just to make clear here, we are calling the /authn api via NodeJS (backend) server, the swapping for access token and refresh token, we are calling required Okta API via NodeJS (backend) server then how okta session will get set in the client browser?
Would you like to elaborate on this?

Thanks

[abole]

Mate, you’ve taught me something! Do you by any chance have an okta reference for the idpDiscovery config feature? I couldn’t see anything on github (though there seem to be multiple 3rd party articles which reference it and it obviously works)

For #2, if you inspect the calls the Okta widget makes, it looks something like:

1. Call to /authn with username and password. the output is a sessionToken and an okta session cookie.
2. Call to /authorize with the sessionToken to get an authcode
3. Front end passes authcode to node app to call /token to get your tokens

If you’re using PKCE all of this can be done relatively safely via the front end these days, but if you have a backchannel, why not use it.

[tparikh]

@abole
Unfortunately, there is no okta reference for the idpDiscovery feature, which indicates about “Username first and if user types an email then password field gets populated”. Actually, in my project there is also a requirement to support idp feature, so I was just exploring on idpdiscovery feature and I got to know about this.
Sorry to trouble you again, For #2, are you trying to say, Call to /authn & /authorize should be done from the front-end side ( React, Angular, etc) instead of NodeJS backend?
If you are saying Nodejs backend then I am wondering, by calling these above API’s via Nodejs Backend then how it will set session in browser? Do you have any reference/sample code to refer?
Actually, we are not using PKCE flow, we are using authorization code flow.

[abole]

Yes, the calls to /authn and /authorize would be by the front end. If you check the chrome dev tools when you’re logging in with the widget you may actually see these happening. The widget uses a /authn call to post in the credentials.

A basic sequence of the flows would be:
Browser → /authn (POST username and password)
/authn → Browser: set session cookie, return sessionToken
Browser → /authorise: send sessionToken
/authorise → Browser: return authcode
Browser or Node → /token: send authcode
/token → Browser or Node: access, ID, refresh tokens (as relevant)

Sorry I don’t have any sample code handy.

[tparikh]

No Problem! Thanks for the guidance and help.

[tparikh]

Hey @abole
Just need one more help on -
How to prevent disabling username text box when IDP discovery turned on for Okta SignIn Widget.
My organization uses an Okta-SignIn Widget Log-in page for one of our applications. If we have idp on then login page looks like below -

When user enter an email/username and click on “next” button then It simply pre-populates the textbox with the username but does not prevent it from being changed or edited.
Refer below screenshot -

.

This makes it impossible for users who may need to update/correct the email or username.

So Is there a setting to alter the behavior of the username/email field so that it doesn’t disable the Email Input?

Thanks

[abole]

Good morning,
Would something like this do the trick?

Login widget without login/password. Only IDP

Hi I want to use Okta Login Widget to authorize users via Facebook only. No email/password is needed. Can’t find how to hide this fields. I use ReactJS. Thanks in advance! [Screenshot from 2021-01-05 21-09-45]

[tparikh]

@abole
Thanks for the response.
We can do the same by using afterRender. Like this -

widget.on('afterRender', function (context: any) {
      if (context.controller === 'primary-auth') {
        const emailInput = document.getElementById('okta-signin-username')
        const emailInputWrapper = document.querySelector(
          '.o-form-input-name-username'
        ) 
        emailInput.removeAttribute('disabled')
        emailInputWrapper.classList.remove('o-form-disabled')
      }
    })

Here just need your thoughts on -
When the user enters in their username, the widget is, in the background, checking their IdP (based on routing rules). I assume an idp call only happens if context.controller === “idp-discovery” phase means when password field is not present on screen.
If user changed their username here, then it will not impact the idp usecase flow?

Thanks

[tparikh]

@abole
Need one more help -
I have to integrate re-captcha with Embedded Okta Sign In Widget page.
Re-captcha work with okta hosted one but we need it to integrate re-captcha with Embedded Okta Sign In Widget.

Let me know if you have any idea on the same?

Thanks

[abole]

Hi @tparikh its not something I’ve had to look into previously. If you’re using OIE (new version of Okta) this seems to be supported out of the box.

If you’re on Okta classic as you’re hosting the form you can implement whichever recaptcha system you prefer. You may be able to do this by setting up a before widget event hook. I can’t seem to find a list of actual events you can hook so some exploration will be required.

The weakness of this is that it will be all client side and visible in javascript, it’s bypassable (which could be fine depending on the sophistication of the attack you’re trying to mitigate). If you need to go the extra mile (e.g. you’re a financial institution) you may need to implement a combination of the above hook to initially check a recaptcha before submission and some kind of back end logic to double check.

One way to do this back end check could be to Token Inline Hook Reference | Okta Developer which will call your recaptcha API. Just be aware these events aren’t guaranteed and if Okta can’t communicate to your event listener, okta ‘fails open’ bypassing this check. If you build your even listener to be as available as Okta, the chance of this should be low.

Depending on how important this is, it may be easier to get migrated to an OIE tenant.

[tparikh]

@abole
Stuck in one place, need your help -
I am using Embedded Okta signIn widget on client side like below -

var signIn = new OktaSignIn(
  {
    issuer: 'https://{yourOktaDomain}/oauth2/default',
    clientId: '{{clientId of your OIDC app}}',
    redirectUri: '{{redirectUri configured in OIDC app}}',
   ....
  }
);

On submit of form, The widget uses a /authn call (POST username and password) to post in the credentials after /authn call, widget call uses a /authorise call.

Lets say if /authorize gets failed in any case then how we can catch the /authorise call error on client side.?
In my case /authorize gets failed and it stays on okta domain page , refer below screenshot -

I want is that when /authorise call gets failed then it should redirect to my login page and show the error on my login page.

Thanks

[abole]

Sorry for the delay in getting back you you - work has been hectic.
Ideally the widget shouldn’t be performing a full page redirect - it normally uses an API call or similiar to /auth and then to /authorize. Two things to check:

• Is there a form submit config on the page where default submit behaviour is NOT being suppressed? This may be causing the full page redirect.
• Is there an access policy setup for the app allowing your user access after authentication? They may be authenticating correctly but failing to exchange the sessionToken for the auth code if the access policy is incorrect.