- Let's Try at First
Implementing an Authorization Server
- Leveraging reference implementations
- How to handle parameters in authorization requests and token requests
- How to handle responses from Authlete API
How to handle parameters in authorization requests and token requests
An authorization server frontend is expected to pass parameters, which are received at authorization endpoints and token endpoints, to respective Authlete APIs as-is, i.e. you usually MUST NOT modify/pre-process them.
For example, if you want to check values of scope parameter in an authorization request, you don't have to have the authorization server to check them before invoking Authlete's /auth/authorization API; the server should include whole query parameters as a value of parameters key of the API. Authlete will be making a response that includes values, that are verified by Authlete, in scope parameter. Then your authorization server frontend will be able to check those verified scope values.
There are some risks to implement your own verification/modification processes before invoking /auth/authorization or /auth/token API; You might fail to use Authlete's functions for OAuth / OpenID Connect, such as protocol handling and error checking. In the worst-case scenario, your authorization server would be non-compliant to OAuth / OpenID Connect if you don't fully understand such standards.
How did we do with this article?