08.05 FAPI 2.0 Certified

FAPI 2.0 is an API security profile based on the OAuth 2.0 framework suitable for protecting APIs in high-value scenarios. 4th of May, we bacame the first CIAM platform to be certified! You can read more about FAPI 2.0, what it introduces, how it differs from FAPI 1.0 and Advanced, and more in the Exploring Financial Grade API 2.0 blog post. If you need a FAPI-grade authorization server, we got you covered. Just create a workspace of the Fintech and mission-critical applications profile, and choose the FAPI specification version you need to comply with.

Cloudentity offers an authorization server that meets FAPI-grade requirements. Fintech and mission-critical application workspaces can be tailored to comply with your preferred FAPI specification - FAPI 1.0, FAPI Advanced, or FAPI 2.0. You have the option to modify your existing workspace settings to adhere to FAPI requirements or create a new Fintech and mission-critical applications workspace. When creating a new workspace, simply select the desired FAPI profile to ensure compliance.

Please note that FAPI 2.0 is still in the draft phase, but certification is possible with the Implementers Draft FAPI 2.0 specification. Be aware that until FAPI 2.0 becomes final, we do not assume responsibility for FAPI 2.0 workspace settings, and we may introduce breaking changes as the FAPI 2.0 specification is refined.

try now

03.05 Added OpenTelemetry Support to All Authorizers

Cloudentity authorizers now offer full support of OpenTelemetry – an observability framework that combines metrics, traces, and logs to monitor and analyze the performance and behavior of distributed systems. Tracing data, a key component of OpenTelemetry, consists of interconnected spans that represent individual units of work within a request, such as function calls or external service requests. Use it to analyze performance, diagnose errors, or for monitoring and alerting purposes.

29.03 One Token To Rule them All - New dcr_manage Scope In OAuth2 Service

One Ring to rule them all, One Ring to find them, One Ring to bring them all, and in the darkness bind them… Wait, that’s not it. We’ve added a new dcr_manage scope to the OAuth 2.0 service. This new scope provides clients with access tokens containing it to access and call DCR (Dynamic Client Registration) management endpoints. These endpoints include GET, PUT, and DELETE methods for any dynamically registered client within the same workspace.

In simpler terms, this DCR extension is a powerful feature that enables a “one token to manage them all” approach to dynamically registered clients. With the addition of the dcr_manage scope, clients can now easily access and manage all dynamically registered clients with a single access token. This eliminates the need for multiple access tokens for different clients and allows for a more streamlined and efficient management process.

This feature also supersedes other settings like registration access tokens. Clients can now use their access token with dcr_manage scope to manage registered clients without having to generate and use multiple access tokens for different purposes.

15.03 Mutliple Tenants Per Email Account and Login Improvements

Since now, you can register multiple tenants under one email account! To cater to this multitenancy improvement, we adjusted the way you log into Cloudentity platform:

1. You will be asked for your tenant name and within which region your tenant is.

   You may notice that we may have already suggested some tenant names for you! We provide you with a list of tenants based on the cookie we use when you access the Cloudentity platform. If you do not see the tenant you are looking for on the list, just select More tenants and provide your tenant’s name and region.

   Users that did not log in during the last 30 days and forgot their tenants' names may use the Forgot? option in the Provide Tenant Details view.

2. You will be asked to log into your account.

   Notice that from now on, if your account has username or phone number provided, you can use them to log in instead your email!

Old Way	This Is The Way
One tenant per email	Multiple tenants per email
	OR THEN

Learn More

Learn more about Cloudentity Multitenancy and its benefits by reading the Reap Benefits of Multitenancy Model in Cloudentity for Your Organization article!

10.03 Configurable Registration Access Token TTL

Previously, the DCR registration token was always valid for 30 days. Now, the TTL is configurable and can be extended. Optionally, the token expiry can be disabled.

You can configure DCR Registration Token settings in your workspace Auth Settings » OAuth » Client Registration view.

06.03 Extend User Authentication Process with Custom Applications

Cloudentity offers two options for extending the user authentication process: Post Authentication scripts and Post Authentication custom applications.

The Post Authentication script allows custom JavaScript code execution upon user’s authentication, enabling the modification of certain authentication context attributes, enhancement of the user context, or triggering custom API calls.

The Post Authentication custom application option allows connecting a Third-party Application to Cloudentity. This application can interrupt the authorization flow after the user logs in using an IDP, redirecting the user to a custom, business-specific application hosted by the customer. This application requires users to complete additional processes or interactions as needed during the authentication process before they can proceed to granting their consent to the client. When the user completes this third-party flow, they are redirected back to the original authorization flow.

Read more!

28.02 Offline Approval for FDX Dynamic Client Registration

We’re excited to announce that Cloudentity’s FDX implementation now supports offline approval of Dynamic Client Registration.

With our DCR offline approval feature, you can register a client app even if it’s currently inactive. This is ensured by the fdx_client_status parameter. Its values are mapped with the FDX client_status values, whereas mapping is based on the client app’s ability to perform token flows. The mapping is as follows:

Initially, the FDX client app status is set to Active.

You can change the initial client status on UI within the Cloudentity tenant under the required workspace Auth Settings > OAuth > Client Registration > Enable Dynamic client registration: ON > DCR Client’s Initial State:

You can also change the status of the registered client app with the new Update FDX Client’s Status PUT endpoint.

This endpoint requires an access token with the update_client_status scope. Pass the required status in the request body, for example: {update_client_status: "Approved"}. No restrictions to status transition are applied.

Cloudentity’s enhanced FDX implementation and DCR support provide ways for a faster, more secure integration between financial institutions and third-party providers. Benefit from the convenience and security of Cloudentity’s FDX and DCR solutions providing compliance with FAPI standards for secure API interaction with consumer consent.

20.01 Passwordless Authentication Support

Passwordless authentication is a way of protecting the user credentials by replacing the traditional, knowledge-based authentication (such as entering a password you know) to a possession-based authentication (such as confirming the login with your fingerprint on a device you own). The possession-based approach has a number of advantages, primarily:

• There is no password so you can’t give it away to a phishing site
• Your credentials are never stored on the server, in fact, they never leave the device used for authentication

The FIDO alliance is an organization trusted with maintaining the standards for passwordless authentication.

When authenticating with Cloudentity Identity Pools, you have the option to use a Passkey instead of relying on passwords.

16.01 Breaking Change: Pagination In Identity Pools List APIs

Pagination has been introduced when calling the List Identity Pools API. Callers can filter by id or name of the Identity Pool, search before or after its id, sort by id or name, order ascending or descending, and limit the number of returned results.

Callers who wish to use this API to return all Identity Pools should either set a high limit or enable pagination in their UI.

09.01 Token Endpoint Authentication Signing Algorithms Are Now Configurable On The Server Level

Token endpoint authentication signing algorithms are now configurable on the server level via the token_endpoint_auth_signing_alg_values parameters, for example:

{
"token_endpoint_auth_signing_alg_values":
  [
    "HS256",
    "RS256",
    "ES256",
    "PS256"
  ]
}

Depending on the server security profile, only specific algorithms are allowed, for instance, for FAPI-based profiles the only supported algorithms are ES256 and PS256. When a client is dynamically registered in Open Banking Brazil workspace with the insurance industry, if the token_endpoint_auth_signing_alg is not explicitly provided, it is set automatically to PS256.

token_endpoint_auth_signing_alg on the client side should no longer use none value as per the OIDC specification.

Instead of none, the value should be empty or set to one of the algorithms supported by the server (see token_endpoint_auth_signing_alg_values_supported in the well-known page). none is still accepted but it’s converted to an empty string.

2022

26.12 Configuration Export/Import

We value your feedback at Cloudentity and are always looking for ways to improve our platform. In response to customer requests, we’ve made enhancements to our configuration export and import capabilities to improve performance.

We’ve updated our import and export APIs to exclude dynamic and non-configuration objects, which speeds up the process. To provide the option to still retrieve these objects, we’ve introduced a new with_data query parameter to the Export Global Tenant Configuration Root API and the Export Tenant’s Configuration System API. When with_data is set to true, these APIs will include dynamic and non-configuration objects in the exported configuration:

• Consents
• ConsentActions
• ConsentGrants
• ScopeGrants
• PrivacyLedgerEvents
• OpenbankingUKConsents
• OpenbankingBRConsents
• OpenbankingFiles
• CDRArrangements
• OpenbankingFDXConsents

Before the change, those fields were populated by default.

16.12 Brand Login Pages, Consent Pages, 2FA Screens, and Much More

Cloudentity is excited to announce the release of custom themes. Administrators can now create and assign custom appearance themes to Cloudentity components to brand them according to their company style. This includes the ability to customize consent pages displayed to users during authorization flows, login pages for users that authenticate with Cloudentity Identity Pools, the Demo Application, Error Pages, and more. The built-in editor provides an IDE-like experience and preview capabilities for creating and styling your template HTML code. Branding your Cloudentity components can provide a number of benefits for your business. It helps to establish and maintain a consistent visual identity, which can improve recognition and trust with your customers, partners, and employees. Overall, branding can help to differentiate your business and improve its overall image and reputation.

07.11 Utilize Improved Identity Pools

We added a bunch of new improvements to Cloudentity Identity Pools:

• User credentials now include the expiresAt parameter. Once the password expires, it fails verification, and the user needs to either reset it or change.

  Password expiry can be utilized when migrating users from external identity sources without their passwords defined. Just provide no password and set the expiry date for a date in the past to trigger password change for your users.

• Added option to set Preferred Authentication Mechanism useful when both password and OTPs are enabled for an IDP. Now, it is possible to pick the default one that shows up on the login screen.

• Cloudentity Platform admin users can now manage user identifiers and addresses within Cloudentity Identity Pools. Admins can add new identifiers with the email, mobile, UUID types, or even identifiers coming from external sources. Additionally, admins can add new verifiable email or mobile addresses for users and define whether the address is verified or not.

  

• Refactored Identity APIs to enable developers to extend them more easily.

26.10 Manage Users' Identifiers and Addresses in Identity Pools

Cloudentity Platform admin users can now manage user’s identifiers and addresses within Cloudentity Identity Pools. Admins can add new identifiers with the email, mobile, UUID types, or even identifiers coming from external sources. Additionally, admins can add new verifiable email or mobile addresses for users and define whether the address is verified or not.

24.10 Cache Request Responses Within Cloudentity Authorizers

We improved Cloudentity authorizer’s integration with the Open Policy Agent’s REGO language, so that the caching features in the REGO http.send() function are effective. You can now use the following fields in your REGO policies:

• cache - Cache HTTP response across OPA queries. Default: false.

• force_cache - Cache HTTP response across OPA queries and override cache directives defined by the server. Default: false.

• force_cache_duration_seconds - If the force_cache field is set to true, this field specifies the duration in seconds for the freshness of a cached response.

In Cloudentity v2.8.0, the authorizers provide an inter-query cache that persists across policy validations, which enables calls to the http.send() method to access cached responses from previous policy validations. The cache is recreated on each API discovery cycle, so the duration of cached responses is limited by the authorizer’s discovery interval.

Authorizer's API discovery configuration

               
                  
discovery:
  enabled: true # when true, API discovery is enabled
  interval: 30s # how often discovery is performed
         
         

The cache size can be configured via the rego_inter_query_cache_size configuration setting for Cloudentity authorizers:

enforcement:
    rego_inter_query_cache_size: 1000000 # maximum size for the Rego inter-query builtin cache

20.10 Full Support for Brazilian Open Insurance

Cloudentity platform now fully supports Brazilian Open Insurance (OPIN) initiative.

• The Open Finance Brazil type of workspace is configured to provide industry-specific OPIN configuration, for example, OPIN scopes.

• Added permission mappings and groups validation required by OPIN. It can be used in the consent creation endpoint.

• Added the following endpoints from the OPIN spec for consent creation and management:

  • Create Insurance Data Access Consent

  • Get Insurance Data Access Consent

  • Delete Insurance Data Access Consent

• Added DCR requirements support coming from the the Open Insurance specification. This includes:

  • Requirement of using mTLS for DCR registration

  • Software statement parsing and validation for the model provided by the specification

  • Software role to scope mapping during DCR

• Extended mTLS aliases in the OAuth wellknown endpoint to include the backchannel authentication endpoint when Client Initiated Backchannel Authentication method is enabled as required by the OPIN specification.

• Add an option to configure supported acr (Authentication Context Class Reference) values in the authorization server’s OAuth advanced settings. Workspaces now use whatever is configured in the settings instead of an internal hardcoded list.

14.10 Bunch of New Articles for Financial Data Exchange (FDX) Compliance

We have added a whole lot of new articles on complying with the Financial Data Exchange (FDX) standards body! Check out brand new solution guide. Learn how to build consent pages that comply with the FDX requirements, how data providers can protect their APIs with Cloudentity, and much more:

• Financial Data Exchange - Secure Data Sharing Enabled by Cloudentity
• FDX Quickstart
• FDX API Security Profile - Workspace
• FDX Consent APIs
• Building FDX-UX Compliant Consent Page
• FDX Data API Access & Protection

21.09 Password Policies for Identity Pool Users

Times, when qwerty1234 was thought to be a safe password, are long gone! Make sure that your users fulfill all of the requirements for safe passwords with Cloudentity password policies. Such policies enable the Identity Pool administrators to specify, for example, the minimal length of a password, number of special characters, and many more.

16.09 Integration with Kusk API Gateway

Kusk API Gateway enables developers to build, validate, deploy, and monitor REST APIs based on Envoy Proxy running on your Kubernetes cluster. Do you know what else can be run in a K8s cluster? That’s right! Cloudentity authorizers! It is now possible to integrate the Kusk Gateway with Cloudentity and protect the APIs deployed behind your gateway with advanced access control measures. The integration is based on the Cloudentity Standalone Authorizer.

1.09 Event-Based Notifications Using Webhooks

With Cloudentity Extensions, you can set up event-based notifications in order to subscribe third-party applications to important events captured by our platform. You can, for example, notify an external CRM system that a user granted their consent for an application registered within your Open Banking workspace, and more.