HomeBlogTechnical Guide: Migration from OAuth 1 to OAuth V2
Guide

Technical Guide: Migration from OAuth 1 to OAuth V2

Discover how to upgrade your API integrations from OAuth 1 to OAuth V2: technical differences, endpoint changes, token management, and best practices for a secure and seamless migration.

1. Migration Overview

The Openapi OAuth service represents the centralized authentication and authorization infrastructure ("secure access key") for the entire API ecosystem of the platform.

The transition from version 1.0.0 to 2.0.0 (V2) is not a simple version update, but a move toward a stateful management model. While V1 was limited to generating access tokens, V2 introduces granular transaction monitoring through Wallet, multidimensional statistics (Stats), and token lifecycle management focused on security rotation.

2. Infrastructure Changes (URLs and Domains)

The migration requires updating network parameters. The most critical change concerns moving from the national Top-Level Domain (TLD) .it to the international .com domain.

Environment OAuth 1 URL (Legacy) OAuth V2 URL (Current)
Production oauth.openapi.it oauth.openapi.com
Sandbox test.oauth.openapi.it test.oauth.openapi.com

Required action: All endpoint references within the source code must be updated. It is recommended to use environment variables or a global "find and replace" procedure to reflect the TLD change from .it to .com.

3. Token Management Evolution

3.1 Endpoint Mapping

V2 adopts a pluralized RESTful naming convention for token resource management. The endpoint for token operations changes from /token to /tokens.

3.2 Creation and Parameters (TokenCreate)

In V2, the POST /tokens endpoint extends granular control beyond simple scopes and ttl fields. The following parameters defined in the TokenCreate schema are now supported: name (mnemonic identifier for audit logs), limit_total (maximum request threshold), limit_paid (maximum paid request limit), ips (authorized IP address whitelist), and wallet_limit (specific budget allocated from the global Wallet).

3.3 Update and Refresh-Token Flow

While in V1 the PATCH method was limited to partial metadata updates, in V2 the PATCH /tokens/{token} method is standardized to support the refresh-token rotation flow. This enables credential rotation and permission updates without invalidating the existing identifier, ensuring operational continuity and improved security.

3.4 JSON Structure Comparison

V2 returns the TokenDetail object (part of the TokenListOrDetail schema), integrating limits and metadata that were previously unavailable.

OAuth 1 Response (Legacy):

{
  "scopes": ["POST:valutometro.altravia.com/valutazione"],
  "expire": 1634223407,
  "token": "5f8711afe4754a532a7a8358",
  "success": true,
  "message": "",
  "error": null
}

OAuth V2 Response (TokenDetail):

{
  "name": "Production_Token_01",
  "token": "6f9822bgf5862b643b8b9469",
  "expire": 1735689600,
  "scopes": [
    {
      "domain": "imprese.openapi.it",
      "endpoint": "base",
      "method": "GET"
    }
  ],
  "limits": {
    "limit_total": 1000,
    "limit_paid": 500,
    "wallet_limit": 50.00
  },
  "ips": ["192.168.1.1"],
  "success": true
}

4. From Credit (V1) to Wallet (V2)

V2 introduces financial management through the Wallet module, ensuring transactional transparency. Balance inspection is now performed via GET /wallet, replacing the old /credit. Transaction traceability is ensured by GET /wallet/transactions, which provides access to transaction history. Unlike the static value in V1, transaction history in V2 is paginated, enabling detailed analysis for high-volume transactional accounts.

5. Monitoring Systems: From Counters to Advanced Statistics

The V1 /counters system, based on rigid time aggregations, has been replaced by the multidimensional /stats engine. V2 granularity enables aggregation by Token, IP, Domain, and Scope. Calls such as GET /stats/ips identify unique IP addresses, GET /stats/apis aggregates API usage by domain, and GET /stats/apis/{domain} provides an exact breakdown of scopes used within a specific domain. Integrated logs are also available for error visibility through /errors.

6. New Exclusive Features of OAuth V2

Version 2.0.0 introduces monitoring endpoints that were previously unavailable:

  • Callbacks (/callbacks): Endpoint for monitoring and verifying the delivery status of callbacks generated by APIs.
  • Subscriptions (/subscriptions): Management and inspection of active subscriptions associated with the account.
  • Error Logs (/errors): Programmatic access to error logs (ErrorLog), essential for real-time integration debugging.

7. Quick Reference Table for Developers

Action OAuth 1 Endpoint (Legacy) OAuth V2 Endpoint (Replacement) Technical Notes
Token Creation POST /token POST /tokens Supports new limits and ips parameters.
Token List GET /token GET /tokens Returns TokenListOrDetail.
Token Details GET /token/{token} GET /tokens/{token} Includes extended metadata.
Rotation/Update PUT /token/{token} PATCH /tokens/{token} V2 prefers PATCH for secure rotation.
Deletion DELETE /token/{token} DELETE /tokens/{token} Immediate resource removal.
Scope Details Not available GET /scopes/{id} Returns ScopeDetail object.
Credit/Wallet GET /credit GET /wallet Transition to a transaction-based system.
Transactions Not available GET /wallet/transactions Paginated history.
Total Statistics GET /counters/total GET /stats Global aggregated metrics.

8. Security and Scope Notes

In OAuth 1, scopes were handled as simple string arrays, whereas in V2 each scope becomes an inspectable resource through GET /scopes/{id}. The response returns a ScopeDetail object including the related domain and endpoint, as well as specific requirements and associated limits (ScopeLimits). The importance of the TTL (Time-To-Live) parameter remains confirmed: best practice recommends using short-lived tokens to minimize the attack surface. If not specified, the system sets a default TTL of one year, and V2 simplifies this management through streamlined rotation using PATCH.

Migration from OAuth 1 to OAuth V2: Complete Technical Guide | Openapi
Share on