Skip to content

Comments

Add decode_access_token to client#768

Draft
Aetylus wants to merge 5 commits intoauthlib:mainfrom
Aetylus:client-decode
Draft

Add decode_access_token to client#768
Aetylus wants to merge 5 commits intoauthlib:mainfrom
Aetylus:client-decode

Conversation

@Aetylus
Copy link

@Aetylus Aetylus commented May 1, 2025

DO NOT SEND ANY SECURITY FIX HERE. Please read "Security Reporting" section
on README.

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Other, please describe:

Does this PR introduce a breaking change? (check one)

  • Yes
  • No

  • You consent that the copyright of your pull request source code belongs to Authlib's author.

Resolves #764

Notes:

  • Currently only implements for the async Starlette client, but if implementation looks good, I can implement the sync version as well.
  • Initial tests have some duplicated code, but I was hesitant to start adding utility functions just for this to avoid that.

@Aetylus Aetylus changed the title Client decode Add decode_access_token to client May 1, 2025

# RFC9068: authorization servers and resource servers must support RS256
if alg_values is None:
alg_values = ["RS256"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alg value should be in the JWT header, so I am not sure this is needed to guess here.

You should be able to achieve the same thing with:

from authlib.jose import jwt
jwt.decode(token, jwks)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I apologize if my understanding of JWT and Access Tokens is a little sparse, but is there no concern with accepting any algorithm in the header? I did some looking around and this article suggests that you shouldn't necessarily trust the header, but unsure how accurate it is:

When verifying or decrypting the token you should always check the value of this claim with a list of algorithms that your system accepts. This mitigates an attack vector where someone would tamper with the token and make you use a different, probably less secure algorithm to verify the signature or decrypt the token.

I'm fine with removing the line and assuming the header alg is safe to use however if that's what we want to do.

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.

Support for decoding existing access tokens

2 participants