feat: add HTTP URL-connection support for Authlete API v3

[meysam]

References

• [ENG-3828]

Context / Summary

Until now this library only offered JAX-RS and Jakarta-based clients for Authlete API v3, which adds extra dependencies and inconsistent error-handling. This PR introduces a pure-Java HttpURLConnection-based client for v3 and refactors the existing v2 client to share all connection, serialization, timeout, and DPoP logic in a new AuthleteApiBasicImpl base class. Consumers can now switch between v2 and v3 clients simply by changing apiVersion in their configuration, with zero behavioral change to v2 and full support for every v3 endpoint.

Description / Changes Made

• AuthleteApiBasicImpl
  • Centralizes HTTP connection setup (timeouts, headers, URL builder)
  • Unifies JSON (de)serialization via Gson/Nimbus and DPoP JWT signing
  • Provides consistent error-handling and retry hooks
• AuthleteApiImpl (v2)
  • Refactored to extend AuthleteApiBasicImpl
  • Replaced dozens of nearly-identical callService*Api methods with a small hierarchy of ApiCaller helper classes (ServiceGetApiCaller, ServicePostApiCaller, ServiceDeleteApiCaller) and a single executeApiCall(…) entry point
  • Reduced boilerplate by ~1,500 lines while preserving full v2 coverage
• AuthleteApiImplV3
  • Implements every v3 endpoint (authorization, token, introspection, device, backchannel, VCI, SSO, JWKS, federation, batch ops, etc.) on top of AuthleteApiBasicImpl
  • Uses PostApiCaller, GetApiCaller or DeleteApiCaller for each endpoint for consistent invocation and error propagation
• RequestableScopes
  • New model class for /api/client/extension/requestable_scopes/* APIs (GET, POST, DELETE)
  • Supported in both v2 and v3 clients
• AuthleteApiFactory
  • Updated to include AuthleteApiImplV3 in the list of known v3 implementations
• pom.xml
  • Bumped nimbus-jose-jwt to 9.31 (property nimbus.version) to support latest JOSE/JWT features required for DPoP

Schema Changes

None

Breaking Changes

None. All existing v2 behavior is preserved; v3 is opt-in via AuthleteConfiguration.setApiVersion("V3").

Testing Instructions

1. Run mvn clean verify to exercise existing unit tests.
2. In a sample client or integration test, configure:

   authlete.apiVersion=V3
   authlete.serviceAccessToken=<valid-v3-token>
   authlete.baseUrl=https://api.authlete.com

3. Execute core flows (authorization → token → introspection → userinfo) and verify the HttpURLConnection-based client works end-to-end.
4. Switch back to apiVersion=V2 and rerun the same flows to confirm no regressions in the v2 client.
5. (Optional) Test advanced v3 endpoints: device authorization, backchannel flows, VCI batch operations, federation metadata.

Screenshots / Snippets

// Example: creating the v3 client and issuing an authorization request
AuthleteConfiguration config = new AuthleteConfiguration()
    .setBaseUrl("https://api.authlete.com")
    .setApiVersion("V3")
    .setServiceAccessToken("eyJhbGciOiJI…")    // a valid v3 access token
    .setDpopKey(dpopJwkJson);                  // optional DPoP JWK

AuthleteApi api = AuthleteApiFactory.create(config);

AuthorizationResponse authzResponse = api.authorization(
    new AuthorizationRequest()
        .setClientId("0cd7e123-…")
        .setScopes(new String[]{"openid","email"})
        .setSubject("user123"),
    new Options().setWantContent(true)
);
System.out.println(authzResponse.getTicket());

Added Tests?

No new tests in this PR.

Related PRs

None

[hidebike712]

Thanks for your changes. I've reviewed the code. Would be great if can chenck them and an unresolved discussion.

[hidebike712]

Thank you! I think it looks good.

[zamd]

I’ve tested the authorization code flow and introspection—it’s working fine.