I’m working with a legacy system that requires a JWT that contains some app_data (contained in the id_token) by using the “openid profile” scopes. I’m using auth0.js. My issue is that I’m having the error The generated token is too large. Try with more specific scopes.. This works when I use server-side authentication.
I understand the length limitation. I first thought I’d simply disable this limit for my specific use case, but I didn’t find any way to do so. So my second and better idea was to first get a normal “access_token” using only the “openid” scope, and then get the “id_token” from Auth0’s API. Similar to how I get the same information using “/userinfo”.
Is there any way I can get a full id_token, like the one I would get if I used the scopes openid and profile, when I already have an access_token?
If not, is there any alternative? I understand it would be better if all the involved servers did not need the full id_token, but for now that’s what I have to work with.
The cause is usually due to a NON-OIDC comformant application requesting profile scope causing 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.
I understand that the system I’m using is not OIDC comformant, and I cannot make the scope smaller since the dependent system depends on it. This is exactly why I’m stuck. Since I cannot change the systems that depend on that data contained in the id_token, I wanted to know:
Is there a way I can get an id_token from an access_token?
That would solve everything, since I can have a nice, lean authentication (with a small token), and request that huge id_token somehow which I can then forward to the legacy systems that require it.
Does that make sense?
I can already access the data that will be in the id_token using the *.auth0.com/userinfo API, but I cannot sign the id_token myself using that data. There are other APIs that actually return an id_token, but none of them allow me to “just” request an id_token from an access_token.
If there’s no way to do that, and there’s no way for me to change dependent systems easily, then I’m stuck Any ideas are welcome.
Hey there @christian.rondeau, there isn’t a way to get an id_token from an access_token. However that shouldn’t prevent you from requesting that from Auth0: Secure access for everyone. But not just anyone. and detailing your use case. On the subject of where to go from here, I am working with our support team to see if we can help provide some direction. Thanks in advance.
After confirming with support @christian.rondeau, access tokens can be used to get user profiles. Would this help in your pursuit? If not, please detail how we can better assist you in your implementation. Thanks!
Hi @James.Morrison , thank you very much for researching this for me!
I know I can get the user profile from the access_token, but the systems I query actually require a JWT that contains the data I need to be embedded, so that won’t help me.
FYI I finally worked around that limitation by deploying a GraphQL server that will have “full” authorization against our “legacy” backend, and this “proxy” will actually validate against Auth0’s /userinfo endpoint. I’d have preferred having a way to “upgrade” my token, but I understand it’s not feasible.
Is the application requesting a token a single page application using implicit mode (response_type is token, id_token or token id_token?). If so, the limit is set at 3.5 K because the response is delivered in a Location header for the redirection to the callback URL, and some browsers limit the length of headers. There’s no way around it unless, except a change in architecture like the one you mentioned above.
If you are using an authorization code flow or hybrid flow (used in regular web apps or native applications, or if you put a back end to your SPA receive and keep the tokens using an authorization code exchange), the limit is removed because the browser does not limit these exchanges.
Any ideas are welcome.