Closed jamieklassen closed 11 months ago
Good find! Definitely want to get https://github.com/backstage/backstage/blob/99978bb0ab0175047340af9453e86cd9004af8e5/plugins/auth-backend/src/identity/router.ts#L37 updated
Not entirely sure what makes sense to list though tbh. If we only list the currently selected algorithm that might actually not be true since we might have old keys laying around in the DB after a reconfiguration. Perhaps simply list all of the ones that the runtime supports? š¤·
according to the spec,
The algorithm
RS256
MUST be included.
but otherwise I was thinking of just reporting the current tokenFactoryAlgorithm
. Maybe the most honest thing to do would be to read the valid keys from the keystore on demand like this:
and check which algorithms appear there -- then the metadata endpoint would be guaranteed to be consistent with the JWKS endpoint. At first this seemed overkill, but after reading through the code it doesn't seem that bad to me.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Tbh I don't think the list needs to be particularly accurate or list only the algorithms that are currently in use by existing keys. It should be alright to list a broader set of possible algorithms that we support instead? Would just hate to introduce the additional complexity and overhead of DB access on that endpoint tbh.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
š Description
There's a discrepancy between the algorithms declared as supported by the OpenID metadata endpoint (
/api/auth/.well-known/openid-configuration
) and the actual ID tokens issued by Backstage.š Expected behavior
The ID token issued by Backstage should be signed with an algorithm which the OpenID metadata endpoint declares as supported.
š Actual Behavior with Screenshots
The only algorithm declared to be supported is
RS256
, but the ID token is signed withES256
and the only advertised JWK is forES256
.š Reproduction steps
Create an OAuth app in GitHub, using these settings:
Generate a client secret for the app
Run
yarn start-backend
withapp-config.local.yaml
:Visit http://localhost:7007/api/auth/github/start?env=development, consent, get redirected back to the handler, and execute this snippet at the javascript console to grab the header portion of the ID token:
Compare these two things:
š Provide the context for the Bug.
I noticed this while helping @RubenV-dev explore a solution for #12394. It's not seriously interfering with anything I need to do, it just seemed like a good idea to be spec-compliant.
Why does this discrepancy occur? Because the openID configuration here:
https://github.com/backstage/backstage/blob/39952df9160c8c3f027a85738e2188fd1f9076fc/plugins/auth-backend/src/identity/router.ts#L37
in many cases doesn't match the actual signing algorithm here:
https://github.com/backstage/backstage/blob/39952df9160c8c3f027a85738e2188fd1f9076fc/plugins/auth-backend/src/identity/TokenFactory.ts#L73
š„ļø Your Environment
š Have you spent some time to check if this bug has been raised before?
š¢ Have you read the Code of Conduct?
Are you willing to submit PR?
Yes I am willing to submit a PR!