1. Getting started
Some customer information needs to be collected before the Connective Identity Hub can be used:
Each client application from the customer needs to define a name.
Another necessary bit of information is the allowed redirect URLs. The Connective Identity Hub is based on the OpenID Connect protocol. OpenID Connect works by redirecting the user between the customer application and the Identification Service. While the user information cannot be retrieved without a password, an attacker may still try to initiate a readout flow and redirect the end user to a phishing website. Each client should therefore specify up-front which redirect URLs will be allowed. An error will be raised if the redirect URL in a given parameter does not match the ones registered in the configuration. A redirect URL should use the HTTP/S scheme, cannot contain any query parameters and must always be passed to the Connective Identity Hub in the exact same way it was registered.
The customer should also indicate which Identity Providers the client should be able to use. It is possible that additional information will be needed when making use of a specific Identity Provider.
Connective can then proceed to initialize the configuration. Once that is done, each client will receive a unique OpenId Connect client_id associated with the client’s redirect URL and a unique client_secret.
The Connective Identity Hub allows two authentication methods to be used for communication with the customer's client application’s backend:
Basic authentication: encodes the client_secret and transmits it through the Authorization HTTP header
POST authentication: sends, amongst others, the client_secret in a form-url-encoded POST body
Which method you should use depends largely on the OpenId Connect library used by the customer application. Either method will have to communicate over an HTTP/S connection, so the password is never sent “in the clear”. Basic authentication is preferred because it allows the HTTP server to quickly filter bad requests.