Token-Based Authentication (TBA) Deprecated — Mandatory OAuth 2.0 Migration

What Changed

Oracle is retiring Token-Based Authentication (TBA) in two phases:

1. 2027.1 — New TBA integrations blocked. You will no longer be able to create new Integration Records that use TBA for SOAP web services, REST web services (/services/rest/record/v1/...), or RESTlets. Existing integrations continue to function.
2. 2028.1 (tentative) — All remaining TBA integrations cease to authenticate. Consumer key/secret plus token ID/secret credential sets will be rejected at login. The sole stated exception is SuiteAnalytics Connect (ODBC/JDBC), which is excluded from this phase.

What Stops Working

• RESTlets — Any N/https or external call that authenticates to a RESTlet endpoint using TBA headers (OAuth realm="..." with consumer/token pairs) will receive an authentication failure.
• SOAP web services — SuiteTalk SOAP calls that pass TBA credentials in the tokenPassport SOAP header will fail. This includes all WSDL-based integrations.
• REST web services — REST record and SuiteQL calls authenticated via TBA OAuth 1.0-style signatures will be rejected.
• Third-party connectors — Boomi, Celigo, MuleSoft, Informatica, and any other iPaaS or app using TBA credentials will require reconfiguration or a version upgrade to support OAuth 2.0 flows.
• Custom scripts and external apps — Anything authenticating with a consumer ID and consumer secret via TBA, whether server-side SuiteScript or external code, will stop working.

What Is NOT Affected

• SuiteAnalytics Connect (ODBC/JDBC) — Explicitly excluded from the phase-2 end-of-support. TBA credentials for ODBC/JDBC connections will continue to work past 2028.1 per current guidance. Oracle has not stated a separate timeline for these.

What to Do

1. Inventory all TBA integrations. Go to Setup > Integration > Manage Integrations. Filter for records where the authentication method is TBA. Also check Setup > Users/Roles > Access Tokens to identify every active token and its associated integration record.
2. Audit third-party connectors. Contact vendors (Boomi, Celigo, MuleSoft, Informatica, etc.) to confirm their connector versions support OAuth 2.0 Client Credentials or Authorization Code flows with NetSuite. Upgrade connectors as needed.
3. Create new OAuth 2.0 Integration Records. For each TBA integration, create a corresponding Integration Record configured for OAuth 2.0. Choose the appropriate grant type:
   • Client Credentials (M2M) — Best for server-to-server integrations with no user context. Use POST /services/rest/auth/oauth2/v1/token with grant_type=client_credentials.
   • Authorization Code + PKCE — Required when user context matters or for interactive apps.
4. Update authentication code. Replace TBA signature generation (OAuth 1.0 HMAC-SHA256 signing of nonce, timestamp, consumer/token secrets) with OAuth 2.0 bearer-token retrieval. Your HTTP calls will switch from an Authorization: OAuth oauth_consumer_key="..." header to Authorization: Bearer <access_token>.
5. Handle token refresh. OAuth 2.0 access tokens expire (default 60 minutes). Implement refresh-token logic or, for Client Credentials, re-request tokens before expiry.
6. Test in Sandbox first. Migrate one integration at a time in a Sandbox or Release Preview account. Verify authentication, role permissions, and record-level access before touching Production.
7. Decommission old TBA tokens. Once OAuth 2.0 is confirmed working, revoke the legacy TBA tokens to reduce your attack surface. Do not wait until Oracle forces the cutoff.

Key Unknowns

The source does not specify:

• Whether the 2028.1 date is firm or subject to further delay.
• Whether existing TBA tokens will be forcibly revoked or simply rejected at runtime.
• Whether SuiteScript server-side calls using N/https with TBA auth within the same account (intra-account) are affected, or only external inbound calls. Verify with NetSuite Support or test in Sandbox once 2027.1 is available.