OIDC: backchannel logout default configuration only accepts a single client id #6149
Labels
Comments
Merged
11 tasks
rhafer
added a commit
to rhafer/ocis
that referenced
this issue
Apr 26, 2023
The "aud" claim of the logout token is supposed to contain the client-id of the client for which the token was issued. Our current implementation of validating that claim is somewhat broken. We only allow to configure a single value for the allowed client id. But we have different client-ids accessing oCIS. This completely removes the current validation of the `aud` claim until we come up with a working solution. As we currently require a session id to be present in the logout token the risk not validating the `aud` claim is pretty low. Related: owncloud#6149
butonic
pushed a commit
that referenced
this issue
Apr 27, 2023
The "aud" claim of the logout token is supposed to contain the client-id of the client for which the token was issued. Our current implementation of validating that claim is somewhat broken. We only allow to configure a single value for the allowed client id. But we have different client-ids accessing oCIS. This completely removes the current validation of the `aud` claim until we come up with a working solution. As we currently require a session id to be present in the logout token the risk not validating the `aud` claim is pretty low. Related: #6149
ownclouders
pushed a commit
that referenced
this issue
Apr 27, 2023
The "aud" claim of the logout token is supposed to contain the client-id of the client for which the token was issued. Our current implementation of validating that claim is somewhat broken. We only allow to configure a single value for the allowed client id. But we have different client-ids accessing oCIS. This completely removes the current validation of the `aud` claim until we come up with a working solution. As we currently require a session id to be present in the logout token the risk not validating the `aud` claim is pretty low. Related: #6149
|
Thanks. I see the PR was merged. IMO that makes sense for the time being. |
|
Fixed. |
github-project-automation
bot
moved this from Qualification
to Done
in Infinite Scale Team Board
fschade
pushed a commit
that referenced
this issue
Jul 10, 2023
The "aud" claim of the logout token is supposed to contain the client-id of the client for which the token was issued. Our current implementation of validating that claim is somewhat broken. We only allow to configure a single value for the allowed client id. But we have different client-ids accessing oCIS. This completely removes the current validation of the `aud` claim until we come up with a working solution. As we currently require a session id to be present in the logout token the risk not validating the `aud` claim is pretty low. Related: #6149
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Our code verifying the backchannel logout token, tries to verify the
audclaim of the token by default. It is possible to configure a single value that is allowed to appear in that claim (defaulting toweb).I think we're doing something wrong here. Keycloak for example by default sets the
audclaim to the value of theclientidfor which the session was created. So with the current approach only sessions initiated one specific oidc client can be logged out (webby default). For sessions created by any other clients (i.e. the desktop of mobil apps) the validation of the logout token will fail because theaudclaim does not match the expected value.As a workaround we can disable the validation of the
audclaim for now withPROXY_OIDC_SKIP_CLIENT_ID_CHECK=trueI am still not sure what the correct validation of the
audclaim would look like in ocis. We simply don't know all the valid client ids that could appear in logout tokens. (At least when DCR is enabled in the idp).The text was updated successfully, but these errors were encountered: