SDK should support `WithOIDCAccessToken` option

[jakedoublev]

Background

Currently, the otdfctl CLI is only able to authenticate users through the client credentials flow, which is itself a limitation of the SDK (relying on the WithClientCredentials option). There is also another supported option WithTokenExchange. However, the CLI and other clients should not be required to necessarily utilize on a token exchange flow when they may be driven by an entity directly (as in the case of a CLI) and there are cases where the client should be of lower trust.

Acceptance Criteria

1. SDK authenticates gRPC requests with a passed in OIDC Access Token
2. Unit tests

[strantalis]

@jakedoublev What if we just exposed this option. This way you can just define your own TokenSource implementation.

platform/sdk/auth/access_token_source.go

Lines 12 to 17 in cfab3ad

	type AccessTokenSource interface {
	AccessToken(ctx context.Context, client *http.Client) (AccessToken, error)
	// MakeToken probably better to use `crypto.AsymDecryption` here than roll our own since this should be
	// more closely linked to what happens in KAS in terms of crypto params
	MakeToken(func(jwk.Key) ([]byte, error)) ([]byte, error)
	}

https://github.com/opentdf/platform/blob/main/sdk/options.go#L96-L100

[jakedoublev]

@strantalis That seems like it would work. There are a couple of abstractions/interfaces that make it a little tricky to know for sure but it would be good to try it out and see. I'm not sure we'll need an http client in the AccessToken method signature for example since we'll have already gone through a flow to get/store an OIDC AT within at least the CLI, but we could just ignore that argument I guess if we indeed don't need it.

[strantalis]

@strantalis That seems like it would work. There are a couple of abstractions/interfaces that make it a little tricky to know for sure but it would be good to try it out and see. I'm not sure we'll need an http client in the AccessToken method signature for example since we'll have already gone through a flow to get/store an OIDC AT within at least the CLI, but we could just ignore that argument I guess if we indeed don't need it.

I am actually not sure why we are passing that in as well. Let me know if I can help with this.