Confusion about signing_key about doorkeeper-openid_connect HOT 4 CLOSED

@yourtallness the public key is provided to clients through the OIDC discovery mechanism, specifically through the standardized /.well-known/openid-configuration endpoint which points to our custom /oauth/discovery/keys endpoint (see https://github.com/doorkeeper-gem/doorkeeper-openid_connect#routes).

Additionally, if we are not using the implicit flow that returns the id_token (e.g. we use the authorization code flow only), we can skip this configuration, correct?

Turns out the gem requires the signing_key even if no id_token is being requested.

Not sure I follow, AFAIK an ID token is always returned in some form when the openid scope is requested. If that scope is not included, this gem shouldn't become active and you're dealing with a normal OAuth flow from the Doorkeeper gem.

from doorkeeper-openid_connect.

I mean that we don't use the implicit flow that returns the id_token.

Our clients will be hitting the userinfo endpoint to obtain the user information.

from doorkeeper-openid_connect.

@yourtallness ok thanks I was confused, I checked the specs and it's possible to send a request with response_type=code where no ID token is returned: https://openid.net/specs/openid-connect-core-1_0.html#Authentication

Can you post the exact error you're running into?

I'm wondering if it would be sufficient to specify nil as default for signing_key in Doorkeeper::OpenidConnect::Config:

from doorkeeper-openid_connect.

Turns out the client had to interface with actually required the id_token to be included in the access_token response, so the use case in the original post is now not applicable to us.

FWIW, I set the signing_key to nil and it worked.
Thanks for the support!

from doorkeeper-openid_connect.