Add support to set TouchID / Windows Hello authentication as preferred_webauthn on config file

[jorgeclaro]

Background

Currently, when multiple WebAuthn (FIDO2) authenticators are enrolled in Okta, gimme-aws-creds always shows the factor picker:

Pick a factor:
[0] webauthn: iCloud Keychain
[1] webauthn: me@company.com
[2] webauthn: Security Key NFC by Yubico

Even if the user wants to consistently use one preferred authenticator, the CLI does not offer any way to remember or auto-select a preferred WebAuthn factor.

Examples:

• Touch ID on macOS
• Windows Hello on Windows
• A YubiKey / hardware security key

Proposal

Add an optional config key to .okta_aws_login_config:

[DEFAULT]
preferred_mfa_type = webauthn
preferred_webauthn = "webauthn: me@company.com"

Behavior

When logging in, the CLI fetches the list of available factors from Okta.

• If the preferred_webauthn matches one of the WebAuthn factors exactly, the CLI auto-selects it.
• If the preferred factor is unavailable (e.g., Touch ID not enabled, Windows Hello locked, hardware key not connected), the CLI falls back to the standard Okta picker.

Existing config keys (preferred_mfa_type) remain fully supported for non-WebAuthn factors (push, totp, etc.).

Benefits

• Reduces unnecessary MFA picker prompts for users with multiple enrolled WebAuthn devices.
• Improves UX for users who want to consistently use Touch ID, Windows Hello, or a specific security key.
• Maintains security: fallback to picker ensures user always explicitly chooses if preferred factor isn’t available.
• Fully backward-compatible: CLI continues to work for users who don’t set the new key.

Notes / Edge Cases

If preferred factor name is not returned by Okta API, the picker should be shown as fallback.

[jorgeclaro]

TouchID/FIDO2 setup:
gimme-aws-creds --action-setup-fido-authenticator
This will store it on: ~/.okta_aws_registered_authenticators

[jorgeclaro]

My earlier closing comment was a misread. --action-setup-fido-authenticator only registers a FIDO/webauthn authenticator with Okta; it doesn't influence which factor _choose_factor selects at login. When multiple webauthn factors are enrolled (Touch ID, iCloud Keychain, NordPass, YubiKey, etc.), the sub-picker still appears every run, which is the exact gap this issue was opened against.

The OP's name-based preferred_webauthn is one viable shape. An alternative that works across all factor types and avoids fragile name matching is pinning by the stable Okta factor id:

preferred_mfa_factor_id = opf9ei43pbAgb2qgc0h7

Applied after the existing preferred_mfa_type / preferred_mfa_provider filters; overrides them when matched. On miss, lists the available ids and falls through to the interactive picker. The picker output also prints the factor id alongside the display name so the id is discoverable without a separate action.

Implementation with tests: #503.

[jorgeclaro]

PR open for review: #503. Implementation as outlined above — id-based pinning applied after the existing preferred_mfa_type / preferred_mfa_provider filters, notify-and-fall-through on miss, picker now prints factor ids for discoverability. Tests included. Happy to adjust the config-key shape if a name-based variant is preferred.