This table will be used when validating Authorization Endpoint Request.
This is a valid request, having valid client_id and redirect_uri.
The response contains a Location header, having the redirect_uri and code as query parameter
The code that is given to the client, is registered in the database. This can also be used for logging.
You can see there is a column called is_used which denotes if the code has been used by Token Endpoint.
We now send a token request that has valid parameters, including the code we just got.
The Authorization Header contains the hash of client_id:client_secret, which is Base64 Encoded.
We get a successful token response. I have yet to implement Token Response. So this is the placeholder for now :D
The Authorization Code in the database is now marked as used, which ensures the same code is not used again.
The Authentication Endpoint accepts both GET and POST requests.
All mandatory parameter validations are implemented.
Some optional parameters have yet to be implemented. The request will still work.
You should only be required to change the config.properties file to modify the database driver and connection, in case you're using a different database and/or different table names.
You should follow the schema in the demo as that's what I had in mind during implementation. The project in its current state will not function properly if you decide to use a different schema. Though if I find time I might work on that but its unlikely I will.
The Authentication Endpoint accepts POST requests only, as specified in OpenID Connect Core Specificaion.
All mandatory parameter validations are implemented.
Same rules as Authentication Endpoint's Configuration.
The Authentication Endpoint accepts GET requests only, as specified in the OpenID Connect Core Specificaion.
There are no query parameters to send to this endpoint.
You will only need to modify config.properties file to setup the values of the different keys in the JSON body.