Cannot Read Properties of Undefined (Reading 'client_token') - Okta Auth Verify Push Challenge

Details
While attempting to log into our Vault server using the Okta auth mountpoint with a valid user and pass -- the VaultPass extension is unable to deal with the Okta Verify Push challenge. A random number is supposed to be presented on the app screen (the extension window) as an additional check to validate your identity, but instead the following error is presented:

Okta KB Link:
https://help.okta.com/oie/en-us/Content/Topics/identity-engine/authenticators/configure-okta-verify-options.htm#:~:text=Number%20challenge%20is%20a%20technique,on%20the%20user's%20mobile%20device.

To Reproduce
Steps to reproduce the behavior:

Fill in Vault server URL, username, password, and choose Okta Auth Mountpoint.
Click Login to Vault.
Hit 'Review' on the MFA request received after correct credentials are entered.
Response is sent back to VaultPass, but error is issued (see above).
Okta Verify Push challenge cannot be completed.

Expected Behavior
To have the VaultPass extension window present the corresponding Okta Verify Push challenge number that the user needs to accept on their phone by choosing the same random number shown.

Screenshots

Browser (please complete the following information):

OS: Windows 11 Enterprise
Type Chrome
Version 107.0.5304.122

Additional Context
N/A

Can you try to use the new "Get Token from Vault" login method in your situation? The way login is built, it is not expected to have a second factor in the process... but taking the final token from the Vault site should still work.

Can you try to use the new "Get Token from Vault" login method in your situation? The way login is built, it is not expected to have a second factor in the process... but taking the final token from the Vault site should still work.

This doesn't appear to work for me, but I wonder if it's due to user error somehow in this case. I can't seem to get the secrets directories to show up under the "secret/vaultPass" root KVv2 mount. Here's the error I'm getting with my policies applied:

I am using the KVv2 secrets engine and did a "vault secrets move" operation to the new mount path, which I just have as "secret/vaultPass"; does it require a specific /ORG/ in the path to be recognized? I decided to omit this since I didn't need it in this case. I feel as though my ACL rules may be incorrect though, coming back to this KB: https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2#acl-rules.

I am double-checking ACLs to confirm and will report back my findings.

Just a quick follow-up here -- I do believe my ACL rules were incorrect as suspected, and I've corrected this with KVv2 pathing. Additionally, my KV root mount was incorrect, citing this duplicate issue noted here: #17. My fault. I've since moved this to "secret/" and does appear to work and get me in. However, I'm getting a different error now after successfully using a token:

Is this still a permissions' issue in some regard with VaultPass? I can confirm I am able to browse to these secrets successfully within the Vault Web UI without issue, but I get this error: "getCredentials: function text() { [native code] }"

Glad you got further!
Is it possible that your credentials are not formatted correctly?! Or maybe one of them isn't?

I assume the error you are seeing is thrown here:

vaultPass/popup.js

Line 169 in edb584e

throw new Error(`getCredentials: ${await result.text}`);

You Chrome/Firefox console might show a bit more error context

Glad you got further!
Is it possible that your credentials are not formatted correctly?! Or maybe one of them isn't?

I assume the error you are seeing is thrown here:

That's correct. I think my issue is that I was typing something weird in my query with slashes, in path notation, thinking that I needed to specify a sub-path and string to get results back, but probably not the case if I'm on a website where the URL is at partially recognized by the [REGEX] field; is that right? Is there a requirement to have the path format exactly this way?

/secret/VaultPass/[ORG]/[REGEX]

For instance, most of our Vault groups and secrets are delineated based on department and sub-dept. like:

/secret/VaultPass/[DEPT]/[SUB-DEPT]/[Account]

Should the URL recognition still work with extra nested secret paths, or is the expectation to have it exactly 2 layers deep beginning after /VaultPass/? Hopefully this makes sense.

Is there a requirement to have the path format exactly this way?

/secret/VaultPass/[ORG]/[REGEX]

For instance, most of our Vault groups and secrets are delineated based on department and sub-dept. like:

/secret/VaultPass/[DEPT]/[SUB-DEPT]/[Account]

Should the URL recognition still work with extra nested secret paths, or is the expectation to have it exactly 2 layers deep beginning after /VaultPass/? Hopefully this makes sense.

@mulbc -- I'm still looking to get clarification on the above. I would have to re-design my folder vault secrets structure to accommodate a single layer deep for the /[ORG]/[SECRET] notation, so it's definitely not ideal... especially because moving credentials seems basically impossible per hashicorp/vault#2414, and the thought of programmatically pulling all creds out just to rebuild them in a slightly different folders seems like a terrible proposition.

I thought about this a bit... sub-orgs/sub-departments are not really something I anticipated in the key-value structure.
One thing I have planned already is to make the path configurable, so that you don't need to necessarily move it because of that. As for the sub-departments...

This is the code that fetches the secrets:
https://github.com/mulbc/vaultPass/blob/master/popup.js#L42

Now if a secret was a path like 'org1/suborg123', your structure might just work.
In order to get there, we would need to make this function smarter and add the capability to detect subfolders that are accesible:
https://github.com/mulbc/vaultPass/blob/master/options.js#L42

Since you appear to be motivated to get sub-folders working, I'm looking forward to a PR that adds this functionality ;)

Hey @bobby-mack - with the new 2.3.3 version we have a configurable path. This might enable you to use your sub-path structure by using /secret/VaultPass/[ORG] as the main path.
The release is in review and should be available through the Chrome&Firefox stores very soon

I thought about this a bit... sub-orgs/sub-departments are not really something I anticipated in the key-value structure. One thing I have planned already is to make the path configurable, so that you don't need to necessarily move it because of that. As for the sub-departments...

This is the code that fetches the secrets: https://github.com/mulbc/vaultPass/blob/master/popup.js#L42

Now if a secret was a path like 'org1/suborg123', your structure might just work. In order to get there, we would need to make this function smarter and add the capability to detect subfolders that are accesible: https://github.com/mulbc/vaultPass/blob/master/options.js#L42

Since you appear to be motivated to get sub-folders working, I'm looking forward to a PR that adds this functionality ;)

Hey @bobby-mack - with the new 2.3.3 version we have a configurable path. This might enable you to use your sub-path structure by using /secret/VaultPass/[ORG] as the main path.
The release is in review and should be available through the Chrome&Firefox stores very soon

Hi @mulbc -- Apologies for my delay in follow-up on all this. Appreciate you looking into it! Admittedly this initiative took a backburner for me as more of a "nice-to-have" versus something critical to support Vault. That said, you definitely answered my initial inquiry on this issue regarding the "get token" functionality for using my current Vault session to get around the Okta Verify check. On the basis of this -- we can consider this issue resolved and closed at this stage.

As for my stretch goals on working with department and sub-department, etc., with several nested levels -- I realize this is easier said than done based on the detection logic required. I may take a crack at a PR if I can wrap my head around how all this works, but I was envisioning some kind of directory traversal code that would systematically check each subsequent directory path if any KV entries are present for either username and password pairs, and then include those matches with the URL RegEx check.