Lack of openid scope in metadata doesn't prevent id_token issuance
Basics
Logistics
Basics
Logistics
Description
We have anomalous behavior in the unexpected case that the metadata doesn't authorize any scopes, at least with regard to the special openid scope. On the authorize endpoint, you typically might not get a sub claim out, preventing anything from "working", but the only barrier to it working is really the attribute release policy.
Assuming you got a sub claim out, you'd possibly get at least a valid authz code (if not other response types), and on the token endpoint, it doesn't prevent issuance of the tokens if the openid scope is missing.
I will commit unit tests documenting these outcomes so that they can be adjusted if the code changes.
Note that it should be possible to change the metadata in between those steps and that should be honored, so even if a sub claim were present and a code issued correctly, if the metadata changes to disallow openid scope, we'd want that to be enforced. So each flow should be doing the right thing without basing the answer on what already happened.
Environment
None
Activity
Show:
Henri MikkonenMarch 1, 2022 at 12:41 PM
Added an activation condition to the actions dealing with id_token generation in the token flow. id_token is now only generated and returned if the validated scope (request verified against scope in the metadata) contains openid.
Also added flow tests to make sure that authorize-flow returns error if openid is not part of the requested scope. The Nimbus decoder requires the scope to exist as it assumes to parse OIDC authentication requests. This should be refactored if we want to support more generic OAuth2 authorization requests.
We have anomalous behavior in the unexpected case that the metadata doesn't authorize any scopes, at least with regard to the special openid scope. On the authorize endpoint, you typically might not get a sub claim out, preventing anything from "working", but the only barrier to it working is really the attribute release policy.
Assuming you got a sub claim out, you'd possibly get at least a valid authz code (if not other response types), and on the token endpoint, it doesn't prevent issuance of the tokens if the openid scope is missing.
I will commit unit tests documenting these outcomes so that they can be adjusted if the code changes.
Note that it should be possible to change the metadata in between those steps and that should be honored, so even if a sub claim were present and a code issued correctly, if the metadata changes to disallow openid scope, we'd want that to be enforced. So each flow should be doing the right thing without basing the answer on what already happened.