8000 More appropriate verification of external token · Issue #40132 · keycloak/keycloak · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
More appropriate verification of external token #40132
Open
4 of 12 issues completed
Open
4 of 12 issues completed
@mposolda

Description

@mposolda

Description

During external-internal token exchange request, Keycloak needs to validate external token. The external token is the token issued by some configured identity provider.

Currently the token validation in token-exchange:v1 is done by:

  • In case that external token is jwt (The subject_token_type parameter is urn:ietf:params:oauth:token-type:jwt), Keycloak is able to validate signature on the JWT (As long as IDP supports verifying signatures with the proper public key) and expiration
  • In other cases (when external token is not JWT, which is the case for most of social providers), the token is validated only by sending request to user-info endpoint.

User-info validation is not sufficient and secure at all. As it may allow any random IDP token of any random client to be successfully used. In other words, someone with Facebook token, which was issued to his own testing client_id could be used to successfully exchange the token in Keycloak side.

  • The proper way should be to use something like introspection-endpoint as that one returns also various details about the client of the token. Like client_id of the client, which issued the token and eventually aud claim with the proper audience of the access token.

  • For the JWT tokens, we currently verify their signature and expiration. It can be still preferred to use introspection-endpoint even for JWT tokens as it is more secure to have response from the server if token is still valid and was not revoked etc. But possibly, introspection may be skipped in case that people explicitly skip introspection or if IDP does not support it

  • More details in the Google doc

Implementation details

This issue is about implementation for the proper token verification in the V2 of external-internal token exchange provider.
For the backwards compatibility, the token-exchange:v1 might still have the same behaviour as before.

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0