Deprecating AuthProvider in favor of Interceptor pattern

[eugenioenko]

Before we release 1.0 there is a window of opportunity for us to fix the organic growth in this repo regarding authorizing requests.

Context

TDF Client was created to use AuthProvider for authorizing request. AuthProvider handles injecting the "Authorization" and the "DPoP" headers.

PlatformClient was added later on and uses Connect Web RPC which expects to use the Interceptor pattern for signing requests.

What we had to do to make it work was create an AuthProviderInterceptor that takes the existing AuthProvider and returns an Interceptor that PlatformClient can use. This is working as expected.

Current State

• TDF Client works only with AuthProvider
• PlatformClient works with AuthProvider (with a gotcha) and Interceptors

*The gotcha of using AuthProvider in PlatformClient:
TDFClient3 call authProvider.updateClientPublicKey() internally modifying the AuthProvider and setting the signing keys.
So PlatformClient can be used with AuthProvider but first authProvider.updateClientPublicKey() needs to be called and awaited.
This is not documented nor explained.

There is a PR that addresses it to a degree: opentdf/web-sdk#883

Proposal

Lets unify the interfaces. Both PlatformClient and TDF Client to use Interceptor pattern. This will:

• Remove the need of AuthProvider
• Remove the need for mapping AuthProvider to Interceptor so that PlatformClient can work
• Remove the responsability of OpenTDF to handle request authentication. OpenTDF is an authorization platfrom, authentication benefits from being handled else where

What will it look like?

const authInterceptor: platformConnect.Interceptor = (next) => async (req) => {
  req.header.set('Authorization', `Bearer ${accessToken}`);
  return await next(req); // Pass the modified request to the next handler in the chain
};

const opentdf = new OpenTDF({
  interceptors: [authInterceptor],
  platformUrl: '/api',
});

const platform = new OpenTDF({
  interceptors: [authInterceptor],
  platformUrl: '/api',
});

Is the const authInterceptor to complex? Lets add a helper function called authTokenInterceptor

const opentdf = new OpenTDF({
  interceptors: [authTokenInterceptor(`Bearer ${accessToken}`)],
  platformUrl: '/api',
});

Thats it, OpenTDF client has authorization headers. Same for PlatformClient.

But what about DPoP?

A good question! A little bit more of research is needed for DPoP, but wouldn’t this be amazing?

const opentdf = new OpenTDF({
  interceptors: [authTokenDPoPInterceptor(`Bearer ${accessToken}`)],
  platformUrl: '/api',
});

Thats it, let the function handle creating the pair of signing keys. Yes, there is a little bit more to it, but from DX perspective, wouldn’t that be awesome?

Rounding Up

We haven’t released the stable 1.0 yet but we are very close. This is our window of opportunity to have it fixed for good

[eugenioenko]

What we gain:

• Single auth pattern — both PlatformClient and OpenTDF use interceptors, no more two mental models
• Kill the updateClientPublicKey footgun — no more hidden ordering requirement where you must await client.ready before PlatformClient works
• DPoP becomes explicit — opt-in via authTokenDPoPInterceptor() instead of a side effect buried in AccessToken internals
• Remove the bridge layer — createAuthInterceptor (the AuthProvider-to-Interceptor wrapper in platform.ts) goes away as production code, only needed for backwards compat
• Simpler standalone PlatformClient usage — no need to construct an OpenTDF first just to get auth working
• Bring-your-own-auth becomes trivial — users behind a proxy or with custom auth just write a 3-line interceptor, no need to implement the AuthProvider interface
• Smaller public API surface for 1.0 — fewer types to commit to supporting forever
• Aligns with Connect RPC idioms — interceptors are the native pattern for @connectrpc/connect-web, so we stop fighting the framework
• Testability — interceptors are plain functions, easier to test and mock than stateful AuthProvider instances with internal token caches

[eugenioenko]

opentdf/web-sdk#899