Corppass Authorization API (FAPI 2.0) Launch

February 23, 2026

Corppass Authorization API (FAPI 2.0) is now available for integration.

It adopts the Financial-grade API (FAPI) 2.0 Security Profile, built on OAuth 2.0 and OpenID Connect, to provide stronger authentication and authorisation through enhanced security controls and standardised flows.

New services must use FAPI 2.0. Existing services onboarded before 23 March 2026 must migrate by 31 March 2027, as the legacy security profile will be deprecated on 1 April 2027. Refer to migration guide

Key Changes

Authorization Flow & Enhanced Security

Pushed Authorization Request (PAR) Flow

• All RPs must implement the PAR flow for enhanced security.

• The authorization request is initiated via the backchannel /request endpoint (PAR).

• Refer to Pushed Authorization Request for more details.

Proof Key of Code Exchange (PKCE)

• PKCE is mandatory for all RPs performing the PAR flow for enhanced security. This provides additional protection against authorization code interception.

• Refer to Proof Key of Code Exchange for more details.

Demonstrating Proof of Possession (DPoP)

• A DPoP Proof JWT must be included in PAR request, Token request, and all subsequent calls to protected resource endpoints (e.g., Userinfo Endpoint).

• Refer to Demonstrating Proof of Possession (DPoP) for more details.

Stricter TTL requirements

• Authorization code expiry is reduced from 10 min to 1 min.

• Refer to Token Endpoint for more details.

Stricter client assertion requirements

• Maximum allowed lifespan for client assertion tokens is now 2 mins.

• Client assertions can no longer be reused. All client assertions must include jti claim to prevent client assertion replay attacks.

• Refer to Client Assertion JWT for more details.

Authentication Context Parameters

• Two new parameters are introduced to support contextualising authentication requests for Corppass Login applications:

  • authentication_context_type (Mandatory)

  • authentication_context_message (Optional)

• See Authentication Context Parameters for more details.

Scopes

• New finer-grained scopes are introduced to provide more control over requested authorization:

  • Authorization scopes

    • authinfo

    • tpauthinfo

  • Entity scopes

    • entity.identity

    • entity.basic_profile.name

    • entity.basic_profile.uen_status

  • User scopes

    • user.identity

    • user.name

• Refer to Scopes for more details.

ID Token and Userinfo Changes

Changes to ID Token Structure

• Adopts a nested structure for better organisation and standard alignment where possible.

• sub claim value now references the subject identifier directly.

• New claims introduced:

  • sub_type

  • sub_attributes

  • act

• Deprecated claims

  • entityInfo -> replaced by sub_attributes

  • userInfo -> replaced by act.sub_attributes

  • email (formerly with restricted access in beta release)

  • email_verified (formerly with restricted access in beta release)

• Refer to ID Token for more details.

Userinfo Endpoint

• The Authorization Info Endpoint (/authorization-info) is replaced by the Userinfo Endpoint (/userinfo).

• The response is returned as JWE (JSON Web Encryption).

• Response payload structure updated:

  • AuthInfo claim -> auth_info

  • TPAuthInfo claim -> tp_auth_info

• Refer to Userinfo Endpoint for more details.

Error Handling

• The API returns standardised OAuth 2.0 error responses across all endpoints, with parameters: error, error_description, and state (where available).

  • API Calls (Back-channel): Direct API requests (e.g., PAR, Token, Userinfo endpoints) return these error parameters in the JSON response body with the appropriate HTTP status code.

  • Authorization Redirects (Front-channel): If a failure occurs during the authorization flow, the user's browser will be redirected to your redirect_uri with these parameters appended as query strings.