Last Updated: Nov 14, 2024
Overview
The below error will be encountered when a user attempts to log in (accessing the Authentication API):
“The generated token is too large. Try with more specific scopes.”
This has resulted in some of our users being unable to login.
Why is this error received, and how can it be fixed?
Applies To
- Authentication API
- OIDC
- Token
Cause
This error can cause some users with big profile data unable to log in.
The cause is usually due to a NON-OIDC conformant application requesting profile scope causing the size of the ID Token to be bigger than allowed. This is because Non-OIDC clients return full user profile when scope profile is requested.
The maximum allowed size for an ID Token is around 3.5kb
Solution
In order to better understand the role and characteristics of ID tokens, we suggest that you read this document.
There are a number of steps that you can take to prevent this error:
- Make the client application OIDC Conformant: OpenID Connect Protocol as that would mean only OIDC standard information is included in the issued ID token and that will significantly decrease the chances of hitting this error
- Remove unnecessary scopes and if ensure that if you’re including custom claims in the issued tokens , ensure that the information you’re including is sufficiently small.
- Check Rules / Actions to whether the ID token is getting assigned big variables
- If requesting user information from a social identity provide, only request the minimum number of scopes that you need.
If you are using Lock, some additional considerations are:
- Lock 11 performs a request when starting up to see if there’s already an authenticated session, and it does so with scope=openid profile email and a response type of token id_token.
- A response type of token id_token has the associated default response mode of using the fragment/hash component of the redirect URL as the way to respond with the requested token.
- A web browser typically put limits on the length of a URL so the server-side of Auth0 service will check the generated token size when the response mode implies including tokens in the URL and fails the request completely it goes beyond a certain size; this is better then leaving the browser to then not handle the full URL and possibly failing silently.
- Currently, the server side always assumes that for a response type of token id_token, the tokens will be included in the fragment of the URL even when the request is performed with an explicit response mode that would not trigger tokens in the URL. Lock 11 makes the request with response_mode=web_message, which would not be subject to browser limits.