Auto-generated state results in a very large response header

[rickygarg]

After making a copy of a project because of domain related deployment restrictions, my new deployment is making oauth2 calls that appear to result in extremely large response headers on the Oauth2 server. If I manually update the state in authUri to something smaller, there appears to be no issue when tested in browser.

Although the behavior of an external Oauth2 server such as Keycloak is outside the scope of this project, if the length of the state variable could be modified within Oauth2 client, it'd be nice to avoid an otherwise unnecessary configuration to increase allowed header size on the oauth2 server.

Currently, the ScriptApp.newStateToken() appears to be a blackbox. The most documentation available appears to only explain usage, but not how it internally sets the state to be used later in usercallback. I was hoping a custom state (say, Utilities.getUUID()) could be accepted as a param to ScriptApp.newStateToken() to give more flexibility to users.

Does that sounds like it could make sense to let users customize state or otherwise configure the length?

[erickoledadevrel]

Unfortunately there isn't anything I can do in this library to influence the size of the state tokens. As you mentioned, they are generated by ScriptApp.newStateToken() which is part of the Apps Script platform and is not code I can directly control. The OAuth2 spec doesn't specify a maximum size for the state parameter, and the current size works well for a wide array of OAuth2 providers, so I don't think the Apps Script team will see a large motivation to adjust their output.

The state tokens are only required when using the /usercallback endpoint, which were designed specifically for this purpose. However some developers have used the Apps Script web app endpoints instead to work around various issues. Those endpoint don't require a state token, but also don't provide the cross-site request forgery (CSRF) protections that the state tokens provide. You could implement that kind of protection on your own, but it's part of the reason why the state tokens are as long as they are.

[rickygarg]

Thanks for the quick response Eric, and the suggested alternate solution of using the web app end point.

It turns out that it wasn't the long state [alone] that caused the large header, as the issue only happened when the user was already logged in. Appears that Oauth2 server logs an _invalidtoken error on grant _refreshtoken, and sends a large response header which I thought was due to the extraordinarily long state [alone]. Temporarily, I've put prompt=login to avoid the refresh_token call altogether while I figure why.

Separately, I wish ScriptApp.newStateToken() wasn't a blackbox, but then again it isn't a part of this repo. Thanks for your help.