Reading the documentation for step-up transactions using acr values: Step-up authentication using ACR values | Okta Developer
If we choose: Phishing-Resistant Hardware-Protected. Requires that you store keys being used to authenticate in secure hardware (TPM, Secure Enclave) on the device. Currently, only Okta Verify meets this constraint. Because hardware protection implies device binding (opens new window), that constraint is selected automatically when phrh is specified. it clearly states that Only Okta Verify satisfies this requirement.
When Okta released the Devices SDK, to build authentication into native apps, they alluded over and over that this was Okta Verify capabilities: Introducing the Okta Devices SDK and API: A Better Way to Secure and Delight Mobile Users | Okta
- " These flows include brandable, embeddable Okta Verify with push notifications and biometric capabilities—all in a single integration."
- “Consistent branding across all of your digital touchpoints is an important way to create a cohesive customer experience. Using the Okta Devices SDK, developers can embed Okta Verify push capabilities into their mobile application, or even build their own branded Okta Verify mobile application. In either case, developers can send customizable, branded push notifications and use biometrics for a frictionless login experience.”
They also talk about how this is device bound. Therefore, would it satisfy phrh in a step-up scenario?