...

1. Client posts the client-id and client-secret to the token endpoint URL using specified authentication type and receives an access token or error message. At this point implementation should cache the token.
2. Client sends the access token to the REST API endpoint using the client_secret_basic authentication type.
3. REST API implementation validates the token using the JWKS URL.

Solution with Control Center

Proposed solution complicates clients configuration and functionality - they need to be configured for each different auth provider and include the functionality of retrieving the access token from the provider.

This could be simplified by implementing the authentication service. In this case the user will get the access token from the Control Center and will pass it to the node, which will verify it in the auth service.

CLI extension

CLI may have special command ignite cluster openid connect which will open a browser with Control Center page where user may specify a 3rd party connector and authenticate via 3rd party cloud provider. After the authentication process will be finished response can be catched via CLI and CC token may automatically stored to CLI configuration.

This is technically not easy to achieve, because the OpenId pipeline requires a callback of success authentication in the form of URL to redirect and it should be mapped to CLI somehow. This is possible to achieve with several options 

1. Start HTTP server on CLI side and generate redirect URL to this server. This approach has problems with port availability for this HTTP server and firewall permissions. 
2. Extend OpenID protocol and create a special polling endpoint on CC side with unique session ID parameter which will be polled from CLI side and trying to get the openID token. This approach has problems with security because it should be a non-authenticated endpoint with only session id validation. 

Tickets