Vault+Okta with MFA

Vault: v1.9.3
O.S.: Centos7
HA = Enabled
storage_type = Consul v1.11.2


It’s a little unclear from the documentation–is it possible to get Vault OSS working with Okta authentication with TOTP MFA? I don’t want to use OIDC, if possible.

If I enable TOTP (as opposed to Okta Verify push), then I relentlessly get this error, seemingly because Okta can’t talk to my (internal) Vault system.

  • Okta Verify Push or TOTP factor is required in order to perform MFA

If I bypass MFA, it works fine.


You’re referring to TOTP or Push MFA from within the Okta auth method itself and not a secondary MFA method, correct?

If so, is the account you’re testing with enrolled with the Okta Verify app?

Are you specifying the totp token at login or waiting for a prompt? (based on what I’m reading in the docs this needs to be specified in your vault login command)

Is the error message you’re seeing returned at the login prompt or is that getting logged in the syslog?

It’s been a while since I’ve used the native Okta auth method but I remember it being a little clunky when I was using it (although I think that was well before built-in MFA support was added).

Thanks for your reply. @jeffsanicola.

Let me be more specific. Our organization uses Okta. Some users use Okta Verify, others use Google Authenticator–there’s no mandate. I’m issuing the following command with the Vault CLI:

vault login -method=okta username=MY-OKTA-USERID totp=ONE-TIME-CODE

That fails with the following error.

  • Okta Verify Push or TOTP factor is required in order to perform MFA

If I remove the “totp=” part, I get the same error. The “totp=” option doesn’t appear to register. If I enter the wrong PASSWORD, however, my authentication will fail–which shows that the first factor is working.

As for your initial question about the MFA workflow, I’m not sure. Okta usually imposes it on our users. Can Vault impose it rather than Okta? Should it? Normally in our environment, Okta is supposed to issue the second-factor challenge.

It’s been a couple years since I used the Okta integration so my recollection is a bit fuzzy, but it was definitely before the “bypass_okta_mfa” parameter was a thing (and as a result before integrated Okta MFA was an option).

If I recall correctly, I had to setup a stand-alone Okta MFA and triggered it via Sentinel policies (and I think only the Push option worked for this). But in order for this to work, the API key used for this portion in Okta required some level of admin rights (not full (Organization?) admin, but like one step below that and I forget what that was referred to). I’m not sure if that was just a quirk of my environment at the time or if that was required for everybody, but I recall MFA not working at all until the elevated privileges were granted to the API key.

Thanks, again.

That sounds like a big hassle, though I imagine things might have evolved in a couple of years.

I saw some indication that MFA was better integrated and fully supported in the Enterprise version of Vault. Disappointing if effectively you have to pay to make MFA work with Okta, but if so, at least that’s a way forward.

Perhaps you’re trouble is also stemming from the Okta API key permissions as well? Not sure what permissions it needs these days but maybe try ramping it up and if that works then scale back until you find the right mix.

Otherwise OIDC has been a breeze to work with in my current environment (using Azure instead of Okta in this one) and the MFA requirements are all handled by the IdP instead of Vault which takes some maintenance and compliance burden off of my team.

Thanks for that–I’m going to exhaust the potential for OIDC before making any judgments.

FYI, we’re running into a similar issue and I filed a bug with an analysis of the faulty code: Okta authentication MFA_REQUIRED case does not recognize GOOGLE provider TOTP type · Issue #14535 · hashicorp/vault · GitHub

(Please upvote the issue by clicking the thumbs-up emoji at the bottom of the first post!)

Thanks for the update!