We’re in the midst of upgrading from lock 10 to 11 and have run into an issue with receiving our tokens.
We have some users who have a large profile/app_metadata (users who belong to a lot of groups and who have a lot of permissions) and when they try to log in we’re returned with the error “generated token is too large”
We were not experiencing this issue with lock 10 and have only run into it since moving to lock 11.
We’ve noted the post here that addresses the same error though in a different context and not in relation to migrating from lock 10 to 11.
We have a react/redux web-app that talks to an API where we decode the JWT to check user permissions. We’re currently using the id-token with the Auth0 Authorization Extension to include the users permissions. Our desire is to maintain this model so that we can avoid having to query Auth0 with each API request to check a users permissions.
We have two queries we’re hoping for some help to answer:
Is the error we’re getting a new restriction with Lock 11 or is it a bug?
If we can’t keep the id-token (or add the claims to the access-token) because the resulting tokens are too large is our only option to check user permissions with Auth0 upon each API request? Or might there be another approach? Could we get the signed id-token in another request where there isn’t a size restriction?
This error is triggered by the Auth0 server, so the Lock version shouldn’t make a difference so long as the authorization flow and requested scopes are the same.
It’s also worth pointing out that you should use the scope attribute of the access token for user permissions rather than ID tokens. You should only use the ID token to validate your user’s identity and retrieve user profile information. Moving permissions to the access token will likely solve this problem too since the ID token will be smaller. See here for more information.
Thank you for your quick response and clarifying for us.
Thanks for the link about access tokens vs id tokens, that was really insightful! The article mentions
“…So unless you are in control of both the client and the API, sending an id_token to an API will not work”. In our case we are in control of both the SPA and the API it talks to. Is it still an anti-pattern to use the id token in this way?
If we do use the access-token instead of the id-token to contain the users permissions/claims would we not run into the same issue of having a token that’s too large? Or is it the case that the access token has the ability to contain a larger amount of data? If so might you know how much more information it could handle?
With regards to your first question, yes, you should only use the access token for authorization.
As far as I’m aware, the token size limit should be the same for both access and ID tokens. I had a further look into it, and there is actually a problem that was introduced in Lock 11 that can result in the token being too large. Lock 11 performs a call to get SSO data that uses the scopes openid profile email. If your client has the OIDC-conformant toggle turned off, it will result in trying to place the full user profile in the token. This can result in the error you saw due to size constraints.
We’re tracking this issue internally, but in the meantime I suggest you try to enable the OIDC-conformant toggle. You can find it under OAuth in your client’s Advanced Settings.
We upgraded from Lock v10 to v11 few days ago, and are bitten by this issue today too. All of our users that have LinkedIn connection are unable to login because a generated token is too large error.
I’m trying to enable OIDC for my auth0 clients. But I’m stuck because I’m not able to retrieve app_metadata which is crucial because we are using Authorization extension.
I set up a rule to add namespaced custom claims, put it under authorization extension rule, changed my auth.params.scope option in Lock to openid email app_metadata roles groups. But app_metadata is not returned from either idTokenPayload or lock.getUserInfo(...).
One strange thing I noticed that, some scope values are ignored when OIDC is enabled.
If I set Lock’s scope to openid email app_metadata roles groups, result returned by lock.on("authenticated" ...) shows scope as openid email. If I set Lock’s scope to openid profile app_metadata, result returned by lock.on("authenticated" ...) shows scope as openid profile. It seems all custom scope values are ignored somehow.
Thanks for your info about “a call to get SSO data that uses the scopes openid profile email.”.
I finally managed to find a temporary workaround by disabling rememberLastLogin in Lock.
BTW, shouldn’t this call use a smaller scope? profile will include a lot of unnecessary data, especially those from social logins.