April 27, 2023

Highlights

DPoP Support

This release introduces basic DPoP (Demonstrating Proof of Possession) support as an alternative to mTLS for client credentials, resource owner password flow, and JWT bearer flows. With DPoP enabled, clients can pass a DPoP header when calling the token endpoint for enhanced security. Authorization code and refresh tokens support is coming soon. Note that this feature is still in draft and is hidden behind the dpop tenant feature flag.

FAPI 2.0 Security Profile Support

Added a brand new FAPI 2.0 workspace profile that complies with FAPI 2.0 Security Profile This profile requires the fapi_20 feature flag enabled.

Breaking changes

[ AUT-8520 ] This update aligns the storage format of webauthn credentials with that of password credentials by converting them into JSON objects. Previously, webauthn credentials were stored as strings, but now both credential types share a consistent and structured format.

Major additions and changes

[ AUT-6620 ] Added Implementation updates for CDR fapi transition phase 3.

[ AUT-7884 ] Each Open Finance API specification has now a separate Swagger model. This change does not affect any API at the functional level, but aims at making Cloudentity Open Finance APIs easier to integrate with.

[ AUT-8704 ] Fix for CDR arrangement customer ids not being propagated to stored refresh tokens.

[ AUT-8732 ] Added documentation for CDR fapi phase 3 transition highlights

[ AUT-8844 ] Add audit event revoked customer_consents for DELETE CDR customer arrangements. Emit audit events per customer’s revoked arrangements.

Minor enhancements

[ AUT-6621 ] Removed refresh_token_expires_at and sharing_expires_at claims in accordance with CDR Fapi Transition Phase 3.

[ AUT-7866 ] Setting correct AMR values for password, otp and webauthn authentication mechanisms:

• Password: pwd
• OTP: otp
• Webauthn: pop

[ AUT-8112 ] Changes for Dynamic Client Registration in CDR Workspaces:

• code response_type is now allowed with the caveat that at least authorization_signed_response_alg is provided for jarm

• ID token encryption is required for hybrid flow (code id_token response_type), which means client configurations of id_token_encrypted_response_alg and id_token_encrypted_response_enc are mandatory in the request

[ AUT-8619 ] Added basic DPoP support as defined in RFC

Clients can now use proof of possession sender constraint as an alternative to mTLS in the following flows:

• client credentials
• resource owner password flow
• jwt bearer

Support for authorization code and refresh tokens are coming soon.

Since DPoP RFC is still a draft, this feature is hidden behind dpop tenant feature flag.

Once the flag is enabled, clients can pass DPoP header (JWT token) when calling the Cloudentity /token endpoint. See examples below:

Encoded header

eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJuIjoidW12MklGaXBxdWdLTG51VmpVRGprV2FWblJkVjFlQlMxYndsV0NTMEZSNW9ZbjUxWGJvV1d6akprOUd6WUtuLU5MRjNnYnY1cm1lM21kX1o0VnJwZXpFVV95QXVVV2k5cGR0NkUtSzVnakM4ZVlTaUkyLTUxSGhUNWpWTHVoc2NIZEQySjlxakU1ckg0QTJXdF9QYnNabjk5VXRnSlNKdjJ4V1VTS1dGMXNNNFRNTzJoRTF2NzdEaFFLdmVSTGlDSko0d3QtTkNPQUh0N2ozRjI0ZHk0QVBXSTM3RVEycGNjeURueWhrRHI5UUQ1S3VKSUdfZXgyMXNtbVJ1ZFpXRGVkN2JnUklGSUF6QjY0UVI1andjVU1CTnBwbmM3dDBCVk5tbFlKVGgyc1pwYnZGTm9FNmtRODNSeFhOMEVKaXpmQ3ZMQTl2VVpQMVVaRDJuZkQ1UC13IiwiZSI6IkFRQUIifSwidHlwIjoiZHBvcCtqd3QifQ.eyJodG0iOiJQT1NUIiwiaHR1IjoiaHR0cHM6Ly9sb2NhbGhvc3Q6NDY2MjkvdGVzdC10aWQtMS1iMWFjMGVlMTQzYjU0YTVjOTlmODdmODg0YzY2NzRjNC9haWQtMS9vYXV0aDIvdG9rZW4iLCJqdGkiOiIzOTVjNGMzNC1kNTIyLTRkOWItOGFjMi05NTJmN2U5ZGNjZDgiLCJpYXQiOjE2Nzk0OTE4MDl9.KJGuORHDOxCvOOZW1E6abmu7_kRCytkc8NTok5dmAWVDqgBc8uGrHvZVINZq7P0iYnqGUy3VOXhZUFW-UXJ6mTwFdeXycY6buTU3Mdbcj8Fj-_-2oBG0J6R18Z369-iqLWJd1PWsvwE4PtAXNlQF5dttbz66n4FaV6VgqOKvyl2M4anAbg2quFQ8XKIElHlWhZMivu6N4ZVkxWHTY7BWGiwejFbjzWvRuR0kT2DZd4ZOaAxHXJfeTYfZxf2MTbZzkEetC92zJ9_3G1Ehhoui8KvKGxR1ttiHPZ_mCHwb_NHLyujMStRjgm4SWEuyavqDPa2W4PHlorgkQW_W2W2CKg

Decoded header:

{
  "alg": "RS256",
  "jwk": {
    "kty": "RSA",
    "n":
"umv2IFipqugKLnuVjUDjkWaVnRdV1eBS1bwlWCS0FR5oYn51XboWWzjJk9GzYKn-NLF3gbv5rme3md_Z4VrpezEU_yAuUWi9pdt6E-K5gjC8eYSiI2-51HhT5jVLuhscHdD2J9qjE5rH4A2Wt_PbsZn99UtgJSJv2xWUSKWF1sM4TMO2hE1v77DhQKveRLiCJJ4wt-NCOAHt7j3F24dy4APWI37EQ2pccyDnyhkDr9QD5KuJIG_ex21smmRudZWDed7bgRIFIAzB64QR5jwcUMBNppnc7t0BVNmlYJTh2sZpbvFNoE6kQ83RxXN0EJizfCvLA9vUZP1UZD2nfD5P-w",
    "e": "AQAB"
  },
  "type": "dpop+jwt"
}

Decoded payload:

{
  "htm": "POST",
  "htu": "https://tenant.us.authz.cloudentity.io/tenant/server/oauth2/token",
  "jti": "395c4c34-d522-4d9b-8ac2-952f7e9dccd8",
  "iat": 1679491809
}

The authorization servers verifies if DPoP header is signed using the public key attached as the jwt claim in the header. The htm and htu must match token endpoint method and url.

After jti and iat succesful claims verification, the authorizations servers responds with the following token response:

{
"access_token":
"eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJhaWQiOiJzZXJ2ZXIiLCJhbXIiOltdLCJhdWQiOiJjbGllbnQiLCJjbmYiOnsiamt0IjoiZDMyd2FlWW85U2pWLXFRVXktZ0V6cXVRcy0yaUpYX0M0X25Ya1hOSVFYbyJ9LCJleHAiOjE2Nzk0OTU0MDksImlhdCI6MTY3OTQ5MTgwOSwiaWRwIjoiIiwiaXNzIjoiaHR0cHM6Ly90ZW5hbnQudXMuYXV0aHouY2xvdWRlbnRpdHkuaW8vdGVuYW50L3NlcnZlciIsImp0aSI6Ijc1NTllNTIyLTZiOGMtNGU3Ny05MzNmLWY4ZjUwMjE0MTQ2OSIsIm5iZiI6MTY3OTQ5MTgwOSwic2NwIjpbXSwic3QiOiJwdWJsaWMiLCJzdWIiOiJjbGllbnQiLCJ0aWQiOiJ0ZW5hbnQifQ._BjDzpD6xS8jBBgwuao0JxMVgWEQW4Fv3kNHpXfc3WAF-rCUrvwOz3Sfgf774mlsOlGuDO9Trii6XqVR1snXFg",
"token_type": "dpop",
}

token_type indicates that access token is DPoP-bound.

The access token (if not opaque) contains additional confirmation claim cnf.jkt with a thumbprint of a public key attached in DPoP header:

{
  "aid": "server",
  "amr": [],
  "aud":
  "client",
  "cnf": {
    "jkt": "d32waeYo9SjV-qQUy-gEzquQs-2iJX_C4_nXkXNIQXo"
  },
  "exp": 1679495409,
  "iat": 1679491809,
  "idp": "",
  "iss": "https://tenant.us.authz.cloudentity.io/tenant/server",
  "jti": "7559e522-6b8c-4e77-933f-f8f502141469",
  "nbf": 1679491809,
  "scp": [],
  "st": "public",
  "sub": "client",
  "tid": "tenant"
}

The introspection endpoint also returns thumbprint under cnf.jkt for DPoP bound tokens.

If the feature flag is enabled, the server well known page will advertise a new field with a list of supported algorithms:

"dpop_signing_alg_values_supported": ["RS256", "ES256", "PS256"]

Client can set "dpop_bound_access_tokens" flag to inform the server that it will always use DPoP. Currently there is no UI for that.

[ AUT-8638 ] Provide more descriptive amr values when doing mfa recovery. The AMR specification states that when returning mfa value, actual methods used to provide multi-factor may also be specified. See Multiple-factor authentication [NIST.800-63-2

[ AUT-8639 ] A new and improved UX has been proposed for OTP entry on various identity pools flows. This change extends the new UX to the reset password and reset passkey flows. See screenshots.

[ AUT-8640 ] This change dynamically disables the submit buttons for various pages if required fields are empty, and enables them once all required fields are filled in.

The logic also respects reCAPTCHAs - so that if a captcha exists on a page, it must be submitted AND all required fields must be filled out for the submit button to be enabled.

This affects the following views:

• Registration (new UX with feature flag enabled) - User details entry
• Registration (new UX with feature flag enabled) - Password entry with/without captcha
• Registration (new UX with feature flag enabled) - Passkey entry with/without captcha
• Registration - Activation screen with OTP
• Activation by invitation email where password is required
• Reset credentials - Requesting password reset with/without captcha
• Reset credentials - Requesting passkey reset with/without captcha
• Reset credentials - Entering new password with OTP
• Reset credentials - Entering new passkey with OTP

Note that login pages already have dynamic button disablement so no changes exist there.

[ AUT-8650 ] Add DPoP support for authorization flow.

Clients using authorization code flow may use DPoP as sender constraint method.

When a token request is received, the authorization server computes the JWK thumbprint of the proof-of-possession public key in the DPoP proof and verifies that it matches the dpop_jkt parameter value in the authorization request (this parameter is optional). The dpop_jkt authorization request parameter only provides similar protections when a unique DPoP key is used for each authorization request.

When PAR is used, there are two ways in which the DPoP key can be communicated:

• The dpop_jkt parameter can be used to bind the issued authorization code to a specific key. In this case, dpop_jkt MUST be included alongside other authorization request parameters in the POST body of the PAR request.

• Alternatively, the DPoP header can be added to the PAR request. In this case, the authorization server checks the provided DPoP proof. It MUST further behave as if the contained public key’s thumbprint was provided using dpop_jkt, i.e., reject the subsequent token request unless a DPoP proof for the same key is provided.

If both mechanisms are used at the same time, the authorization server rejects the request if the JWK Thumbprint in dpop_jkt does not match the public key in the DPoP header.

[ AUT-8701 ] This PR adds domain as an SSO configuration parameter for OAuth servers. The value of this config is used as the Domain for SSO cookies. If no value is set or the value is set to “”, the domain defaults to the server domain, according to the HTTP cookie spec.

[ AUT-8707 ] Create new user modal to create another user when the checkbox enabled.

[ AUT-8718 ] Add a fallback for revocation channel parameter in CDR revoke arrangement API

[ AUT-8721 ] Added fapi_20 workspace profile compliant with FAPI 2.0 Security Profile This profile requires fapi_20 feature flag.

[ AUT-8740 ] Fix incorrect value of cdr_arrangement_id ID token claim / top level CDR introspect attribute set after the amendment flow.

[ AUT-8768 ] Fixes for Custom Theme Editor in the admin UI:

• Updating folder list based on current files: replaced “Reset Password Successful” with “Reset Credential Successful”
• Adding “Register”, “Set/Reset Passkey”, “Address Verification Completed”
• Updating static data to make more previews work, including OtpLength for pages using new OTP styling

[ AUT-8786 ] Created view in admin UI for configuring SSO parameters. The view is available in the Identity Providers section, in the Single Sign-On tab.

Note that the feature flag single_sign_on needs to be enabled on the tenant level in order for the Single Sign-On tab to be visible.

[ AUT-8814 ] Added SSO logout capability to existing logout API.

[ AUT-8830 ] Add support for ConnectID compliant server (security profile).

[ AUT-8858 ] Add require_request_or_request_uri_parameter configuration in server’s advanced settings.

Bug fixes

[ AUT-8714 ] Execute node server.js directly to avoid npm cache issues

[ AUT-8717 ] Fixed a bug with IDP discovery instant-redirect not propagating full set of oauth session query parameters.

[ AUT-8742 ] It is now possible to mark scope as transient using the admin UI

[ AUT-8765 ] Removed required nonce claim in request objects for the fapi 2.0 workspace.

[ AUT-8826 ] Previously the authorizers produced “request validated” info log with output attribute containing a map of string to []bytes that was unreadable. Now, the output map has values printed as string.

[ AUT-8860 ] CDR do not send ADR notifications / consents revoked audit events if no arrangements have been revoked in delete customer arrangements and delete arrangements by client id APIs

[ AUT-8892 ] Fix for accounts:* scope not being created in Open Banking KSA workspaces.

Recommended Database Versions