Migration from Permissions

Consent 3.0 replaces the legacy PermissionId which was used in Consent 2.0 (CaaS) with standard OAuth 2.0 access and refresh tokens.
To ensure a smooth transition, Service Users can migrate existing permissions.

CaaS vs CF - Why This Migration Applies only to CaaS

• CaaS clients (Consent 2.0) used PermissionIds. bLink stored the Service Provider tokens internally and refreshed them on behalf of the Service User. These PermissionIds must be migrated into standard OAuth tokens.

• CF clients (Consent 2.0) already store and use Service Provider–issued OAuth tokens directly.
  No migration flow is required. The first refresh under Consent 3.0 automatically returns a grant_id and transparently upgrades them to the new model.

Why is a migration necessary?

Under Consent 2.0 with CaaS, Service Users accessed Service Provider APIs using PermissionIds, while bLink maintained and refreshed Service Provider tokens behind the scenes. This model provided convenience, but it diverged from modern OAuth standards and limited interoperability.

Consent 3.0 introduces a token-based authentication model, enabling:

• Alignment with OAuth2 / FAPI 2.0
• Simplified Security assumptions
• Predictable integration patterns for Service Users
• Clean separation of responsibilities (Service Users own the refresh flow)

Migration is therefore required for all existing PermissionIds.

Migration Flow Overview

Important - Who Needs to Migrate?

Only CaaS clients must run the migration flow.
CF clients already use Service Provider–issued OAuth tokens and are automatically migrated on their next refresh (the SP adds the grant_id).

1. Permission to Token Exchange (one-time)
   The Service User exchanges a PermissionId for a standard OAuth 2.0 token.
   For CaaS, bLink performs a refresh using the internal Service Provider refresh token to obtain new Service Provider tokens including a grant_id, then issues new bLink tokens to the Service User.
   The Permission will be invalidated after a short grace period or on the first successful request using the new access token.

2. Token Refresh (ongoing)
   After migration:

   • CaaS clients receive bLink‑issued OAuth tokens, bLink swaps these tokens for Service Provider tokens on every API call.
   • CF clients use Service Provider‑issued tokens directly, bLink simply forwards them to the Service Provider.
     Service Users refresh using the standard OAuth refresh flow.

For the detailed sequence, example HTTP requests and responses, see
Migration Flow.