Repository navigation
okta: stop storing raw tokens in the session cookie - #17
Merged
Merged
Conversation
Logging in via Okta could fail on the callback with "500 - securecookie: the value is too long: 4128". The callback saved both the raw ID token and the raw access token in the gorilla/sessions cookie store. Okta ID tokens grow with the user's claims (notably a large groups claim), and once encrypted and base64 encoded the two tokens exceeded securecookie's default 4096 byte limit, so Save failed. Neither token is read after login: the ID token is verified once in the callback, and Ensure only checks that the session value is non-empty. Store a "verified" marker under the existing id_token key instead and drop the access token, which keeps the cookie small regardless of token size. Also delete the one-time nonce once it has been consumed. Existing sessions still authenticate (the key is unchanged and non-empty). Users who already hold an oversized cookie should clear cookies for the site once.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Details:
Issue:
User was
getting 500 – securecookie: the value is too long: 4128 after signing in through Okta.Root cause:
Logging in via Okta could fail on the callback with
500 - securecookie: the value is too long: 4128. The callback saved both the raw ID token and the raw access token in the gorilla/sessions cookie store. Okta ID tokens grow with the user's claims (notably a large groups claim), and once encrypted and base64 encoded the two tokens exceeded securecookie's default 4096 byte limit, so Save failed.Neither token is read after login: the ID token is verified once in the callback, and Ensure only checks that the session value is non-empty. Store a "verified" marker under the existing id_token key instead and drop the access token, which keeps the cookie small regardless of token size. Also delete the one-time nonce once it has been consumed.
Existing sessions still authenticate (the key is unchanged and non-empty). Users who already hold an oversized cookie should clear cookies for the site once.