What's New

Acquaint yourself with the latest enhancements integrated into the world of organizations in the Admin platform. Delve into the B2B Delegated Administration Portal to manage organizations effortlessly. Now, you can extend organization management capabilities to your business customers and partners, empowering them to handle organization accounts, add user populations, manage users, and much more with ease.

We've tailored these updates to foster a more collaborative and delegated administration environment, ensuring smooth operations and enriched interactions among your business network. The upcoming global release of this feature underscores its pivotal role in fortifying B2B interactions and administrative delegation within SecureAuth.

With a global rollout coming soon, now is the opportune time to familiarize yourself with these new features, ensuring a seamless transition and readiness to harness the full potential of the enhanced B2B Delegated Administration capabilities. Your proactive engagement with these updates will position you well for the enriched administrative experience that awaits.

If you do not have Organization and Delegated Administration capabilities available in your tenant yet, contact Support.

Explore the release of a rejuvenated Admin platform navigation. We've reimagined the navigation to be simpler and more intuitive ensuring a user-friendly experience that enhances your interaction with the platform. This is a fantastic opportunity to familiarize yourself with the improved interface and the seamless navigation experience awaiting you in the forthcoming release.

New navigation is enabled for all new tenants. For already existing tenants, it will be enabled shortly. If you want to explore it now, contact Support.

Added node-env/5 dependencies and make timeouts configurable.

New libraries:

Additionally, bumped the axios library to the newest version.

In just a few days, we've supercharged our Identity Pools with essential password-related features:

Stay tuned! These advancements will be integrated into the UI shortly.

Implemented backwards compatibility adjustments from the Brasil Open Finance Specification for the payment consent APIs.

We've added a couple of new audit events that you can utilize to have a greater control over what changes are introduced within your tenants:

Changed the admin- / developer-level Create OAuth/SAML Client API to not assign hybrid response modes by default when the application is created using the single_page / server_web / mobile_desktop application types.

Single Sign-On (SSO) Capabilities replaces the authentication context caching. If your organization used this mechanism, switch to Enable SSO in Identity Providers settings.

FDX DCR available globally. From now on, the registration_endpoint points to the /fdx/dcr/register instead of the regular /oauth2/register DCR endpoint.

Previously, pwd (authentication with a password) was the only allowed amr (authentication method reference) for the NIST-AAL-1/2/3 authorization policies.

Now, the NIST-AAL-1/2/3 authorization policies include otp (One Time Passwords -- Verification Codes) and pop (passkeys) as the allowed amr allowing users to authenticate using these other mechanisms.

Organizations can set up persistent user sessions with single sign-on to allow their customers/users to authenticate just once and access multiple apps.

Extended the Open Finance Brazil Consent Management APIs to support requests including v3 payments:

When a v3 payment consent is targeted with the delete APIs, it receives a rejection reason JSON:

{
 "rejectionReason": {
  "code": "REJEITADO_USUARIO",
  "details": "O usurio rejeitou a autorizao do consentimento"
 }
}

In order to avoid configuration issues where the Kong authorizer's configuration differs too much from the helm chart values, certificate details need to be provided as part of the httpServer.certificate setting instead of the httpServer setting to closely match what Kong Authorizer supports.

With this change, support for httpServer.certificate.generated_key_type and httpServer.certificate.password settings was also introduced.

Organizations that use third-party Identity Providers to sign in to the Admin platform or web applications protected by the authorization server may enable automatic user provisioning to Identity Pools for:

User Provisioning

We are proud to announce the addition of the FDX 5.3 security and consent compliance profile to our rich portfolio of open finance compliance profiles. It enables financial institutions and open banking platforms to quickly upgrade to FDX 5.3 and achieve instant compliance.

The recently released FDX API 5.3 introduced the requirement for data providers to align the Consent Grant details and OAuth scopes. It may sound like a mysterious technical detail to many but it is critical for interoperability, security, and compliance.

We have addressed this and other consent and OAuth details in our FDX compliance profile. It lets data providers offload the complexity of continuous compliance with evolving FDX consent and API security profile.

Add new set of APIs (create, get, update, delete and list) for new entity authorization details. The feature is currently available behind the feature flag.

Authorization detail is an object defined in the OAuth RAR spec used to specify fine-grained authorization requirements. An admin can define multiple authorization details within a workspace. Authorization detail has a reference to a service and must have unique type. Additionally for every authorization detail schema must be defined, for example:

{
   "type": "payment_initiation",
   "locations": [
      "https://example.com/payments"
   ],
   "instructedAmount": {
      "currency": "EUR",
      "amount": "123.50"
   },
   "creditorName": "Merchant A",
   "creditorAccount": {
      "bic":"ABCIDEFFXXX",
      "iban": "DE02100100109307118603"
   },
   "remittanceInformationUnstructured": "Ref Number Merchant"
}         

A minimal schema must have at least a type property:

{
  "properties": {
    "type": {
      "description": "type",
      "type": "string",
      "minLength": 1
    }
  },
  "description": "basic user data",
  "type": "object",
  "required": [
    "type"
  ]
}         

Added the Get User Details by Key API allowing to retrieve user information by user's identifier or a verified address.

Updated swaggers and models in accordance with the newest release candidate for the Open Finance Brasil consents API.

We added a bunch improvements to the process of connecting SAML IDPs:

IDP Connection	IDP Configuration

You can now configure custom Token and Code Time-to-Live periods for client apps that take precedence over the TTLs you apply at the authorization server level (Settings >> Tokens >> TTL). Learn how.

It is now possible to assign Token Claim Enrichment Extensions directly to a client application. Extensions attached at the client level affect only the client they are assigned to and are executed after Extensions at the server level (if there are any). Learn how.

User Management	Organization Management

CIAM B2B Portal allows to administer organizations and their user populations without any technical hassle. You can delegate organization administration to your partners/customers and empower them with the self-management of users, configuration of sign-in options, roles configuration, and application permissions.

Single Sign On Authentication (SSO) allows your users to log in just once to an application connected to CIAM and use the resulting session as a proof of authentication to all applications in the workspace for as long as the session is valid, thus removing the need to re-authenticate when the user wants to use another app.

SSO can be configured in a workspace Authentication > Settings > Persistence view.

Currently, the SSO feature is behind a feature flag. To enable it, contact Support.

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.

We offer 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.

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.

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.

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

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

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 OAuth > Authorization Server > Client Registration view.

We offer 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. 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!

We're excited to announce that our 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 tenant under the required workspace OAuth > Authorization Server > 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.

Our 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 our FDX and DCR solutions providing compliance with FAPI standards for secure API interaction with consumer consent.

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:

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

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

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.

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.