The behavior of the Configuration API can be customized through the use of several extension points that control the steps that occur when a dynamic client registration request arrives.
First, the incoming request is validated to ensure that it is syntactically valid and semantically correct. The result of the validation process is a model which will either contain error details or a validated Client model.
When validation succeeds, the validated request is passed on to the request processor. The request processor is responsible for generating properties of the Client that are not specified in the request. For example, the client_id is not normally specified in the request and is instead generated by the processor.
When the processor is finished generating values, it passes the final client object to the store and returns an IDynamicClientRegistrationResponse indicating success or failure. This response object is finally used by the response generator to generate an HTTP response.
Each of the validation and processing steps might also encounter an error. When that occurs, errors are conveyed using the DynamicClientRegistrationError class.
To customize the validation process, you can either implement the IDynamicClientRegistrationValidator interface or extend from the default implementation of that interface, the DynamicClientRegistrationValidator. The default implementation includes many virtual methods, allowing you to use most of the base functionality and add your customization in a targeted manner.
Each virtual method is responsible for validating a small number of parameters in the request and setting corresponding values on the client. The steps are passed a context object containing the client object that is being built up, the original request, the claims principal that made the request, and a dictionary of additional items that can be used to pass state between customized steps. Each step should update the client in the context and return an IStepResult to indicate success or failure.
For more details, see the reference section on validation
In a similar way, the request processor can be customized by implementing an IDynamicClientRegistrationRequestProcessor or by extending from the default DynamicClientRegistrationRequestProcessor. Again, the default request processor contains virtual methods that allow you to override a part of its functionality.
For more details, see the reference section on request processing
Finally, to customize the HTTP responses of the Configuration API, you can implement the IDynamicClientRegistrationResponseGenerator or extend from the default DynamicClientRegistrationResponseGenerator.
For more details, see the reference section on response generation