This epic gives the driver a full interactive browser login: a three-hop Auth0 PKCE chain that mints Confluent's own control-plane and data-plane tokens, refreshed by a background daemon and shared process-wide. Unlike the sibling BYOIDC epic — where the caller supplies an external token good only for the Flink data plane — a Confluent-minted control-plane token reaches the whole surface: Flink plus Tableflow, Connect, and CMK. One human login collapses up to three API-key pairs into one credential.
The neighboring Java client (confluent-flink-plugin-private#399, squash 64b3b17, FTAB-97) shipped machine-to-machine OAuth — a static token or a refreshing client-credentials provider — but never an interactive browser login, the /api/sessions → /api/access_tokens control-plane chain, or a process-wide multi-Connection holder. Those are this epic's distinguishing work: the reach the plugin's Flink-data-plane-only scope never had to touch. (The plugin's BYOIDC modes are covered by the sibling #148 instead.)
This epic reuses the polymorphic _flink_auth slot and the connect() auth-mode selection point that #100 / PR #146 built (the first step of the BYOIDC epic). It does not depend on that epic's child 2; the two epics diverge past the shared seam and can proceed in parallel.
Alas, dbapi is synchronous/blocking python, so we have to resort to using threads / a short lived webserver thread to receive the success/failure oauth callback. A new markdown document in there repo (for reviewer / claude reference) describes how concurrency will be handled in the face of multiple Connections in multiple threads (a many-threaded dbt session kicking off) each racing to start up the oauth process.
Remember while implementing:
- We're using branch
oauth-epic-integration as integration branch off of main for all of the child issues to base off of. When epic functionality is complete, we'll then merge into main, but we'll PR each reasonable piece at a time.
- Read and review all child issues to gain context on where the current issue sits in the grand scheme of things to be sure to not do more than is needed in any individual child.
This epic gives the driver a full interactive browser login: a three-hop Auth0 PKCE chain that mints Confluent's own control-plane and data-plane tokens, refreshed by a background daemon and shared process-wide. Unlike the sibling BYOIDC epic — where the caller supplies an external token good only for the Flink data plane — a Confluent-minted control-plane token reaches the whole surface: Flink plus Tableflow, Connect, and CMK. One human login collapses up to three API-key pairs into one credential.
The neighboring Java client (confluent-flink-plugin-private#399, squash
64b3b17, FTAB-97) shipped machine-to-machine OAuth — a static token or a refreshing client-credentials provider — but never an interactive browser login, the/api/sessions→/api/access_tokenscontrol-plane chain, or a process-wide multi-Connection holder. Those are this epic's distinguishing work: the reach the plugin's Flink-data-plane-only scope never had to touch. (The plugin's BYOIDC modes are covered by the sibling #148 instead.)This epic reuses the polymorphic
_flink_authslot and theconnect()auth-mode selection point that #100 / PR #146 built (the first step of the BYOIDC epic). It does not depend on that epic's child 2; the two epics diverge past the shared seam and can proceed in parallel.Alas, dbapi is synchronous/blocking python, so we have to resort to using threads / a short lived webserver thread to receive the success/failure oauth callback. A new markdown document in there repo (for reviewer / claude reference) describes how concurrency will be handled in the face of multiple
Connections in multiple threads (a many-threaded dbt session kicking off) each racing to start up the oauth process.Remember while implementing:
oauth-epic-integrationas integration branch off of main for all of the child issues to base off of. When epic functionality is complete, we'll then merge into main, but we'll PR each reasonable piece at a time.