Skip to content

docs: correct misleading "encrypted" claims for signed-only auth cookies - #694

Open
sridhar-3009 wants to merge 1 commit into
Neoteroi:mainfrom
sridhar-3009:docs/fix-misleading-encrypted-cookie-claims
Open

docs: correct misleading "encrypted" claims for signed-only auth cookies#694
sridhar-3009 wants to merge 1 commit into
Neoteroi:mainfrom
sridhar-3009:docs/fix-misleading-encrypted-cookie-claims

Conversation

@sridhar-3009

Copy link
Copy Markdown

Summary

Several docstrings describe cookies set by CookieAuthentication.set_cookie, CookiesTokensStore (and the two OIDC result-handler methods that use it) as storing encrypted id_token/access_token/refresh_token values. They're actually only signed, via get_serializer()itsdangerous.URLSafeSerializer. URLSafeSerializer provides integrity/tamper protection (an HMAC signature) but no confidentiality: the payload is base64-encoded plaintext, trivially decodable by anyone with access to the cookie (e.g. via browser devtools, a proxy, or a logged request).

This is just how itsdangerous works by default (same as Flask's session cookie, for reference) - not a code defect - but the docstrings actively claim the opposite of what happens, which could lead someone to store more sensitive data in these cookies than they otherwise would, believing the contents are hidden from the client.

Change

Updated the docstrings in:

  • blacksheep/server/authentication/cookie.py (CookieAuthentication.set_cookie)
  • blacksheep/server/authentication/oidc.py (CookiesTokensStore class docstring, and both get_success_response methods that reference it)

to accurately describe the cookies as signed (not encrypted), and to note that contents remain readable to anyone with access to the cookie.

No behavior changes - this is a documentation-only fix.

Test plan

  • Full test suite: pytest tests/ → 1922 passed, 1 skipped (unchanged from baseline)
  • black --check, isort --check-only, flake8 all clean on changed files

CookieAuthentication.set_cookie, CookiesTokensStore, and the OIDC
result-handler docstrings described id_token/access_token/refresh_token
cookies as "encrypted". They're actually only signed via
itsdangerous.URLSafeSerializer (get_serializer), which provides
tamper-protection but no confidentiality - the cookie payload is just
base64, readable to anyone with access to the cookie.

Clarify the docstrings so users don't mistakenly assume these cookies
hide sensitive claims/token contents from the client.
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.

1 participant