Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support additional response_types #56

Open
dmfs opened this issue Sep 19, 2018 · 1 comment
Open

support additional response_types #56

dmfs opened this issue Sep 19, 2018 · 1 comment

Comments

@dmfs
Copy link
Owner

dmfs commented Sep 19, 2018

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?
@dmfs
Copy link
Owner Author

dmfs commented Sep 19, 2018

This is an interesting read which explains why these types are needed: https://medium.com/@robert.broeckelmann/understanding-openid-connect-series-37c93d25e92b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant