Skip to content

Don't check the at_hash (access token hash) in OIDC ID Tokens if we don't use the access token #18374

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
May 2, 2025

Conversation

anoadragon453
Copy link
Member

@anoadragon453 anoadragon453 commented Apr 29, 2025

It doesn't appear necessary to check this value if we don't end up actually using the data it refers to.

This was motivated by our work against the TI-Messenger spec. In our setup, we're receiving the ID Token from the upstream IdP, yet it has an invalid at_hash field. We're currently communicating with the IdP's maintainers as to why this is.

In the meantime, we've theorised that checking this field isn't actually necessary in our case. Synapse only uses the access token for fetching user metadata from a separate endpoint:

async def _fetch_userinfo(self, token: Token) -> UserInfo:
"""Fetch user information from the ``userinfo_endpoint``.
Args:
token: the token given by the ``token_endpoint``.
Must include an ``access_token`` field.
Returns:
an object representing the user.
"""
logger.debug("Using the OAuth2 access_token to request userinfo")
metadata = await self.load_metadata()
resp = await self._http_client.request(
"GET",
metadata["userinfo_endpoint"],
headers=Headers(
{"Authorization": ["Bearer {}".format(token["access_token"])]}
),
)

But we don't do this in our setup, as all the user's metadata is included in the ID Token itself. Thus, we never actually use the access token, and it seems silly to validate it.

Currently we're working around this issue in our setup by stripping the at_hash field from the ID Token in a network proxy before Synapse receives it, but this seems like the cleaner solution.

FYI authlib is the one that actually validates this field, here. It only does so if the access_token parameter is set in the claims dict, which is what this PR is disabling when unnecessary.

Pull Request Checklist

  • Pull request is based on the develop branch
  • Pull request includes a changelog file. The entry should:
    • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
    • Use markdown where necessary, mostly for code blocks.
    • End with either a period (.) or an exclamation mark (!).
    • Start with a capital letter.
    • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
  • Code style is correct
    (run the linters)

… don't use the access token

It's not necessary to check this value if we don't end up actually using
the data it refers to.
@anoadragon453 anoadragon453 marked this pull request as ready for review April 29, 2025 17:59
@anoadragon453 anoadragon453 requested a review from a team as a code owner April 29, 2025 17:59
To provide a further layer of abstraction should we start to use the
access token in other places.
To check that Synapse validates this token in unit tests correctly.
@anoadragon453
Copy link
Member Author

@MadLittleMods I've added both a _uses_access_token property (good suggestion!) and a unit test. Please have another look.

@anoadragon453 anoadragon453 merged commit fd5d3d8 into develop May 2, 2025
4 checks passed
@anoadragon453 anoadragon453 deleted the anoa/dont_check_at_hash branch May 2, 2025 11:16
sandhose added a commit that referenced this pull request May 2, 2025
sandhose added a commit that referenced this pull request May 2, 2025
#18374 did not pass linting
but was merged
MatMaul pushed a commit to tchapgouv/synapse that referenced this pull request May 12, 2025
MatMaul pushed a commit to tchapgouv/synapse that referenced this pull request May 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants