Extend the OAuth2 connector so a reconnect can request the union of
previously granted and newly requested scopes without losing either.
Four related changes:
- Connection gains Scopes() []string so callers no longer need a type
switch to reach the scope set. OAuth2Connection and APIKeyConnection
implement it; SlackConnection inherits via embedding.
- OAuth2State carries RequestedScopes and CompleteWithState falls
back to it when the provider omits the scope field (RFC 6749 §5.1
allows this when granted equals requested). Without the fallback
the stored Scope would be empty and the next reconnect would have
no diff base.
- providerDefinition gains SupportsIncrementalAuth, set only for
Google Workspace. When the flag is true and the caller passes
InitiateOptions.IncludeGrantedScopes, the auth URL carries
include_granted_scopes=true and the prompt=consent param is
dropped so reuse flows see only the delta consent screen.
- InitiateOptions gains ConnectorID so the reconnect case is passed
explicitly instead of relying on the caller to mutate r.URL.Query.
Signed-off-by: Aurélien Sibiril <81782+aureliensibiril@users.noreply.github.com>
Add an InitiateOptions struct to the Connector interface so each
caller can declare the scopes it needs instead of having them baked
into the connector at registration. The HTTP handler reads repeated
?scope= query parameters from /connectors/initiate and forwards them.
Also restore GOOGLE_WORKSPACE and LINEAR provider definitions which
were silently dropped from the bootstrap config refactor.
Signed-off-by: Aurélien Sibiril <81782+aureliensibiril@users.noreply.github.com>
Add API key connector protocol, OAuth2 client credentials
grant, token refresh config, provider info endpoint,
ConnectorProviders helper, and bootstrap configs for all
OAuth providers. Move OAuth2 state decode near type.
Signed-off-by: Aurélien Sibiril <81782+aureliensibiril@users.noreply.github.com>
Add database field level encryption level to sensitive data to reduce
the risk in term of data leak. I dedice to have only one key for now in
a near future I may move to one master key and one encryption key per
organization to make rotation easiest.
I don't use built-in pg_crypto function to have clear seperation and
avoid any encryption key leak.
Signed-off-by: Bryan Frimin <bryan@getprobo.com>
