Forum Discussion
Combine Okta and 2FA(not Okta!) in one login entry
Hi!
A bunch of web applications allow you to use Okta to log into them, but additional security requires 2FA(TOTP) codes as well.
Namely, I run a private instance of GitLab and Grafana, which both allow authentication (and authorization) via Okta, but after the initial login step also ask to put in an OTP.
I have a login entry that works fine with the Okta itself(login and password plus push message confirmation). Also, I have a login entry with the OTP required to log in to the private GitLab instance.
However, the usage flow is a bit convoluted in this setup.
First GitLab shows an embedded Okta screen and that gets automagically filled in by 1Password. Then it redirects to the GitLab site itself and asks for the one-time-password, but at this point, 1Password doesn't realize that it has OTP for this website and presents a huge list of remotely related login entries.
Eventually, I can scroll down to the right one and fill in the OTP, but this is suboptimal, to say the least.
So, is there a way to have login entry in the 1Password for that given site which would use Okta entry for initial login(seems to work fine) and then put OTP stored in it?
I tried to use the "Related items" link to cross reference both entries, but that had zero effect.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser: Not Provided
1 Reply
- 1P_Timothy
Community Manager
Hi instanttim! Thanks for writing in and sharing your experience. I'm very sorry for any frustration or inconvinience this has caused. Your feedback on it is greatly appreciated though as we continue to expand and optimize this new space.
You've diagnosed the issue quite accurately. For our previous community, you could sign in with either a username or email. The new community requires a username. So, if you're updating your password for the new community, your email may be saved in the username field of the original login item. Further to your point, many sites use username interchangeably with email, so I would agree it's easy to dismiss the "username" heading on the field.
I could definitely see the benefit in changing the error message to better hint at the fact that username vs. email may be the issue, or in including more signposting through the password reset flow.
Thanks again for your feedback on this, I've shared your comments with the team. If we can help with anything else, just let the us know!