In order to support OpenID Connect it needs to be checked to which extend we need to support other response_types and response_modes and how these could be implemented (using as much of the existing code as possible).
Some open questions are:
- If the auth code token response also contains an
id_token, why would I want to request it with request_type=code id_token?
- Likewise, why would I want to send a
request_type=code token id_token?
- If there are valid use cases for the two points above (which are not covered by
request_type=code, how can we tell AuthorizationCodeGrant to use the fragment rather than the query part of the redirect URL? Do we need another HybridGrant for that?
- How to tell an
ImplicitGrant to also request the id_token type?
- (How) Do we support
ImplictGrant with only a id_token and no token? Maybe as a new ImplicitIdTokenGrant?
In order to support OpenID Connect it needs to be checked to which extend we need to support other
response_types andresponse_modes and how these could be implemented (using as much of the existing code as possible).Some open questions are:
id_token, why would I want to request it withrequest_type=code id_token?request_type=code token id_token?request_type=code, how can we tellAuthorizationCodeGrantto use the fragment rather than the query part of the redirect URL? Do we need anotherHybridGrantfor that?ImplicitGrantto also request theid_tokentype?ImplictGrantwith only aid_tokenand notoken? Maybe as a newImplicitIdTokenGrant?