authz_server/authorize endpoint refactor

[matteo-cristino]

The authorize should be a visitable html page that open from the wallet should let you see you a list of fields declared by a schema (for example username and password) that the user should fill and on that data the custom code is performed (for example call to backend to verify the userr) if the call is successfull then the authorize contract is performed returning the code.

Open question: if a get is performed at the authorize endpoint then the reponse (the html file) will not be compatible with the oauth specs. In his case whould we return particular error?

[matteo-cristino]

Moreover some data obtained from the login can be helpfull later, thus the custom code should return a list or dictionary (do not know what is better) that would be then added to the authorization_details already present in the slangroom memory (with a new statement) so that these data is available to both /token and /introspection endpoint for other uses

[matteo-cristino]

Add a precondition that check for the request to be valid (add a new statement on slangroom for that)

[matteo-cristino]

The authorize page should accpet more than 1 custom contract. An easy solution can be that the custom code is not directly present on the hmtl page, but the contract inside it do a POST to the custom API on the server with the login data in the body.

Another solution, but seems a more complex, is to crate a html template and when running make up this template is filled with all the custom codes.

[matteo-cristino]

To sum up:

• precondition checks the request_uri validity (contract in public/.auhtorize.slang)
• type of credential must be retireved from the backend from the request_uri: Create an API on authz_server that given a request uri returns the type of credential -> API name: /ru_to_toc
• login page is rendered and handle based on the type of credential
• auhtorization details retireved from login should be passed along the request_uri and the client_id to another authz_server API that update the authorization details in the state and returns the authorization code -> API name: ru_to_ac

The two APIs (in particular the second one) should onyl be accessible from the login page after the login to avoid people not doinfg the login and calling directly that API, how can this be achieved?

Finally, how does the authroization code is returned to the user? Printed on the screen? 🤷🏽

[matteo-cristino]

Everything done, just a small issue remain. Moved to #111