"The generated token is too large" error is returned from the Authentication API

Knowledge Articles
1

Problem statement

When we access the Authentication API, we sometimes see the error:

“The generated token is too large. Try with more specific scopes.”

This has resulted in some of our users being unable to login. Why are we getting this error and what can we do to fix it?

Symptoms

Typically this error will be encountered when a user attempts to login. If a Client is configured to have the OIDC conformant toggle disabled; this means that when you make a request that includes the profile scope the server will try to bundle the entire user profile in the ID token (not just the OIDC standard claims that would be associated with that scope)

Cause

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 taken 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 that the information you’re including is sufficiently small.
  • Check Rules / Actions whether the ID token is getting assigned big variables
  • If requesting user information from a social identity provider, 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 assume 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