This section covers the authentication stage. This involves a consumer verifying who they are with their data holder.
<aside> <img src="/icons/info-alternate_gray.svg" alt="/icons/info-alternate_gray.svg" width="40px" /> New URL December 2, 2024
The CX guidelines have been re-launched on a new domain: cx.dsb.gov.au
For more information, refer to Change log: Consumer Experience (CX) Guidelines
</aside>
<aside>
Authenticate is the second stage of The Consent Model.
The authentication stage involves a consumer verifying who they are with their data holder. This is required so the data holder can connect the data recipient's authorisation request to the correct CDR consumer. The standards support multiple authentication methods to give consumers a safe, familiar, and consistent experience while ensuring flexibility for data holders and recipients.
Redirect to App (R2A) provides a faster, safer, and more convenient way for consumers to authenticate when their data holder’s app is installed on their device. This app-based flow supports strong methods like biometrics and PINs, and must be implemented by data holders and data recipients by 10 May 2027.
As per the Fallback Authentication Framework, where Redirect to App is unable to be used for the purposes of CDR authentication, and Decoupled Authentication is not supported, data holders are required to continue providing support for Redirect to Web with One Time Password (OTP) flow. This ensures consumers can always complete the process by verifying their user identifier and entering a one-time code.
Example of the flow where the consumer authenticates with the data holder’s app. Read more about Redirect to App.
Fallback Authentication Framework
Example of the flow when Redirect to App is unable to be used for the purposes of CDR authentication, and Decoupled Authentication is not supported. Read more about the Fallback Authentication Framework.