The landscape of digital experiences is rapidly evolving – consumers expect more than ever. Organizations of all kinds are under pressure to deliver user experiences that rival those of industry giants in tech and retail. However, this push for innovation comes with increased risks like threats, fraud, and regulatory requirements. In highly regulated sectors such as banking, insurance, or healthcare, the sensitivity of transactions and data amplifies the need for stringent security and compliance controls. As such, striking the right balance between strict security measures and a seamless user experience is crucial for success.
To harmonize security with UX for sensitive operations, we’re launching Okta Highly Regulated Identity (HRI) on Auth0 by Okta. This Financial Grade Identity™ feature set incorporates advanced security protocols (FAPI), high assurance step-up authentication (Strong Customer Authentication or SCA), Customer Managed Keys, and additional custom policy controls and UX enhancements for approval flows. These elements are essential for constructing real-world solutions that empower users to safely and intuitively handle sensitive operations such as money transfers, payments, or accessing health records.
In this series of posts, we'll dive deep into the complex questions and challenges your may encounter when dealing with sensitive operations, and how Okta Highly Regulated Identity can provide solutions.
Also, if you want to shape our Highly Regulated Identity solution, consider applying to our Limited Early Access Program as explained at the end of this post.
What is FAPI?
OpenID FAPI is a suite of security and privacy specifications developed by the OpenID Foundation that serves as a unifying framework. This framework is strategically designed to elevate the security landscape concerning the utilization of APIs for accessing financial and other sensitive data and services.
Within this framework, stringent requirements are established, mandating that APIs adhere to these standards to attain the "financial-grade" classification. This designation signifies the API's capability to robustly manage sensitive data, along with offering robust authentication and authorization mechanisms.
FAPI has been widely adopted by the industry in different regions and environments. It is the foundation for the security profile of the UK Open Banking regulation as well as the security guidelines proposed by the Financial Data Exchange (FDX) for North America. The broad acceptance of FAPI underscores its significance as a global standard in fortifying API security within the realm of financial and other highly regulated, sensitive data access scenarios. You can read more details here.
Through the implementation of these critical features, Auth0 offers a standardized approach to secure access to financial and other types of sensitive data, services, and transactions through APIs, which ultimately helps you build trust and confidence in these highly regulated markets.
Let's take a look at some of the questions and challenges you'll face when building real-world services in this context.
Is the User Who They Say They Are?
The first problem you will face when dealing with highly sensitive operations is providing the right level of assurance for the user’s identity.
The user's journey begins with redirection from your service or another third-party source to your Auth0 tenant's /authorization endpoint, where users must validate the initial authentication factor, provided that there isn't an active session already. However, in many cases, this initial authentication may not suffice to guarantee security. You will find it necessary to step up authentication and perform what is commonly known as Strong Customer Authentication (SCA).
SCA, originally introduced by the Second Payment Services Directive (PSD2) within the European Union (EU), mandates the use of at least two distinct authentication factors out of the following three:
- something the user knows (e.g., a password),
- something the user possesses (e.g., a device),
- and something intrinsic to the user (e.g., a fingerprint)
These elements must be independent so that compromising one does not jeopardize the others. This safeguards authentication data.
To help with this, Auth0 offers various authentication factors the users can enroll and be challenged within the scope of a login transaction. Specifically, the following factors are compatible with transactions protected with Highly Regulated Identity:
- Mobile Push notifications
- SMS
- WebAuthn
You won't need to establish a static configuration for when and how to employ these factors. Instead, you will be able to inspect transaction details in our extensibility engine (Actions) and dynamically determine which of the above authentication factors to use. This flexibility allows you to make decisions from your custom code based on specific transaction characteristics and add just the right amount of friction to optimize the UX (for example, add a second factor only for payments above 10 $).
Did the User Provide Informed Approval?
Providing the end user with details about the transaction —for their explicit validation and approval— is not only important for UX, but also key for regulatory compliance.
To securely enable this, Okta Highly Regulated Identity incorporates support for RAR - Rich Authorization Requests. RAR allows clients to pass fine-grained authorization data describing the transaction in a JSON object called authorization_details to the OAuth authorization endpoint for the authorization_code flow.
The following is an example of authorization_details for a digital payment:
"authorization_details": [
{
"type": "one_time_payment",
"amount": {
"amount": 2460,46,
"currency": "USD"
},
"sourceAccount": "xxxxxxxxxxx4567",
"recipient": "Acme Travel, Inc.",
"concept": "All Inclusive Resort Packate for Two",
}
]This information is used to prompt the user with the transaction details for approval. These transaction details are tied to the step-up process itself to achieve Dynamic Linking:
- Use push notifications to show transaction details and get approval on a separate device, for example, a mobile phone
- Use SMS, email, or WebAuthn to confirm the details on the device that originated the transaction after the user completes the second authentication factor.
If the user confirms the details, the transaction progresses and an access_token is issued, including the now approved authorization_details. By completing the authorization process in this way, your API servers will later be able to validate the approved details when receiving and servicing API requests.
Is My Solution Secure End-to-End?
Real-world scenarios are complex and have multiple vulnerability points that must be protected with a stronger emphasis on highly regulated environments and services. Okta Highly Regulated Identity enables the different steps and interactions between actors that are involved in sensitive transactions, for example, for handling digital payments, as shown in the next image.
In the example above, the user is redirected from the Ecommerce site to the Bank to confirm the payment during a transaction. Auth0 kicks in to securely authenticate the user and get the transaction approval before confirming the operation to the Ecommerce site so that it can execute the payment on a Bank's API. To set the foundation for a simple and safe end-to-end process, security must be prioritized at every point. Let's see how!
Confidentiality & integrity protection
Authorization details may include account numbers, monetary amounts, merchant names, and other highly sensitive information that must be hidden at vulnerable parts of process, such as URLs used from the user’s browser or access_tokens themselves. This keeps the information confidential, prevents unauthorized access and ensures it is not tampered with.
Protect sensitive data in the front channel
Two different measures are offered as part of the FAPI 1 Advance Security profile.
PAR (Pushed Authorization Requests) introduces a new endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request. In response, it provides them with a reference to this deposited data to be used in a single subsequent call to the authorization endpoint.
This is a simple concept that delivers great benefits.
- First, as this is an authenticated endpoint, we can do early validation: authenticate the application and validate the requested parameters at the beginning of the transaction before redirecting the end-user. It is not ideal to redirect users to show them an error page, and now we can avoid that.
- Second, and very importantly, it avoids passing the authorization parameters via the front channel (i.e., the browser). Instead, they are passed in the body of an authenticated backend request protected with HTTPS so, the Authorization Server knows 1) where it's coming from 2) that it has not been modified along the way by an intermediary. Plus, URL length restrictions on the browser are not a constraint anymore.
JAR (JWT-Secured Authorization Request) is an OAuth2 protocol extension that enhances the security of authorization requests. It does so by using a JSON Web Token (JWT) request parameter to protect the integrity and, optionally, the confidentiality of the authorization request parameters.
When using JAR, the client creates a JWT that includes the authorization request parameters, signs it with its private key, and sends it to the authorization server. The authorization server then verifies the signature using the client's public key, and if the signature is valid, extracts the authorization request parameters from the JWT and processes the request as usual. While PAR provides the integrity and confidentiality protection by means of a simpler solution, JAR is still required to be used in combination with PAR for two main reasons:
- It is required by FAPI 1 Advanced profiles and associated regulations
- Request parameters protected with JAR can also be stored and used to provide non-repudiation, as they are signed by the originator.
Protect sensitive data in access_tokens
As we mentioned, the authorization_details approved by the end user are added to the issued access_token to complete the authorization to access your APIs. To protect that information from data breaches on the Application side or from unauthorized inspection into API calls by intermediaries, Okta Highly Regulated Identity ships support for using JWE - JSON Web Encryption to encrypt the payload of access_tokens.
This allows you to establish the public key to be used to encrypt tokens per API/audience. Tokens can later be decrypted by API servers with access to the corresponding private key, thus making the token opaque for any other entity or intermediary.
Enable a stronger Application authentication
Another potential vulnerability lies in direct interactions from the Application with the OAuth endpoints of your Auth0 tenant, where the Application is required to authenticate. To improve your security posture against person-in-the-middle and other attacks, Okta Highly Regulated Identity provides support for two alternative options considered by FAPI 1 Advanced specification, eliminating the need to send client secrets over the network.
The first option, already available in General Access for Highly Regulated Identity and Enterprise customers, is Private Key JWT: an asymmetric authentication method involving the generation of a public-private key pair to use as credentials to authenticate an Application. You provide the public key and securely store the private key in your own systems without sharing it with us. Subsequently, you use the private key to sign requests sent to your Auth0 tenant by adding a client_assertion. You can read more details in our reference documentation.
As an alternate option, you can opt for OAuth 2.0 mTLS for Application authentication. In this case, you register a standard X.509 certificate linked to an Application of your tenant. The certificate can either be CA-issued or self-signed. The private key corresponding to this certificate is then used on the client side, following standard mTLS procedures, to negotiate and establish the mTLS tunnel when sending requests to the endpoints of your Auth0 tenant. This allows us to authenticate the Application without the need to transmit any secrets over the network. To simplify this method and leverage already existing mTLS infrastructure, our design enables the customer’s edge network to validate the certificate and establish the mTLS tunnel with the Application while sending us appropriate information about that validation in HTTP headers, similarly as we currently do for Custom Domains.
In both of the above options, you can rotate credentials with zero downtime by temporarily keeping two active keys/certificates at the same time for a given Application.
Make sure tokens can’t be used by attackers
Supporting mTLS comes with an additional advantage: token binding, also known as sender constraining. The concept is straightforward - a thumbprint of the client certificate used for mTLS tunnel establishment is added to the issued access_token. This enables the API Server to verify whether the client is utilizing the same client certificate when consuming an API with that access_token. Consequently, even if the access_token is compromised, it remains unusable to malicious actors who lack access to the associated client certificate.
Note this feature operates independently of the Application's authentication method and does not require the pre-registration of the client certificate. Instead, it can employ any client certificate for establishing the TLS connection used to request the access_token. This enables the API Server to confirm if the Application possesses the same client certificate used to acquire the access_token, regardless of which certificate it may be.
Can I customize the user journey depending on the transaction details?
When designing real-world, delightful experiences, it's essential to balance user experience and security. Instead of applying rigid, one-size-fits-all static configurations for all transactions, it's often necessary to add the right amount of friction depending on transaction details. These details span from the monetary amounts involved to the specific nature of the operation. Context plays a key role in encompassing variables such as user identity, device used, and other criteria.
To enable this dynamic behavior, Okta Highly Regulated Identity is integrated from the beginning with Actions, our main extensibility engine. Using Actions, you can customize the authentication process. Once the user completes the initial authentication step, you can inspect transaction details received via RAR, list the user's enrolled and already validated factors and interact with external services (such as risk evaluation engines). Your custom code will be able to determine the next authentication factor to use, if any, depending on all this information.
You can also control the information presented to the user throughout their journey using new page templates for New Universal Login. This allows you to provide instructions on the multi-factor authentication waiting screen and specify the attributes displayed on the approval screen, depending on the type and the rest of authorization_details of that specific transaction.
As we mentioned at the beginning of this post, upcoming posts will dive deeper into the technical details of the different Highly Regulated Identity features. Stay tuned!
Applying for Early Access
Okta Highly Regulated Identity launches in Limited Early Access this November! If you are interested in participating, please reach out to your account manager or fill out this form.
Kindly note that this Limited Early Access program is exclusively available to customers and prospects in North America, the UK and the EU only. We will only reach out to candidates who are well-suited for the program.
