Skip to content

Add decode_access_token to client #768

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

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

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
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy