Question: How should SDK handle refreshes and logouts?

[jakedoublev]

The OpenTDF Platform is in a unique situation because it is a resource server and NOT an identity provider, though the core feature of the platform being authorization means it is inherently tied to identity. Keycloak is used as the reference idP, but it is worth explicitly noting that the Platform is not an idP and should be cross-idP compatible.

The SDK currently supports these WithOpts for authentication:

1. client credentials
2. token exchange
3. certificate exchange
4. OAuth Token Source

When dealing with client credentials, it's an OAuth flow and not an OIDC flow, so there is no refresh token, and the SDK handles expiry with a new token get using the same credentials.

When dealing with the OAuth token source, the SDK currently does no refreshing and errors in the event of expiration.

I have not investigated refreshes with token/cert exchange and how we do/might handle expiration of tokens in the SDK when initialized with those options.

There is also a desire to support DPoP (distributed proof of possession) throughout the platform, which is currently not fully supported.

Some questions arise.

1. Should the SDK always, sometimes, or never handle refreshes of credentials? If sometimes, under what authentication flows would refreshes be expected?
2. Should the SDK always. sometimes, or never expose logout/revoke functionality for the authentication methods?
3. Are there other flows the SDK should support for authentication that are currently unsupported (API token, PAT, app-based via private key)?
4. Does DPoP and the need to sign the methods/uris of requests made by the SDK affect the outcome of any above?

The following scenarios must be considered:

1. browser PEPs
2. serverside PEPs
3. CLI person entity users
4. CLI non-person entity users (workflows, jobs, actions)