Deprecated skipStateCheck flag

[ibrahimqasim-abtrace]

To preface, perhaps this should also be in the oauth4webapi discussions.

Is it really necessary for the skipStateCheck flag to be deprecated to mark it as a warning? I feel like there are lots of reasons for needing to skip the state check, e.g. any stateless application, and the suggested example of draft-bradley-oauth-jwt-encoded-state-09 or something similar would make perfect sense, essentially using the passed state to match against something and then checking the nonce.

For example, I have a fully serverless application, so how is it possible to maintain state between user-agent requests in order to be able to retrieve the correct state parameter to pass to the expectedState in the authorizationCodeGrant?

I suspect the answer will be to use HTTP cookies or just deal with the deprecated warning (e.g. here), but just wanted to check.

[panva]

For example, I have a fully serverless application, so how is it possible to maintain state between requests in order to be able to retrieve the correct state parameter to pass to the expectedState in the authorizationCodeGrant

For example - encrypted cookies, persistant kv storage, anything we generally tend to use in web apps to maintain state.

If you use state for, well, state and have no other means of csrf or code injection protection (pkce, oidc nonce) and the deprecation warning was the reason you stopped to think about why you shouldn't have the need to use it? Yeah, it's doing the job I envisioned for it.

if you do use cookie based pkce (as you should anyway) then ignore the warning, just make sure your state is signed and cannot be forged.

[panva]

Yeah, an encrypted serialized session cookie or a regular backend stored session with an identifier in a cookie, regardless, an httpOnly; cookie that is cleared when you consume the callback.

[panva]

So, to summarize, do you think having the deprecation triggered you to look into the subject and improve your deployment's security posture?

[ibrahimqasim-abtrace]

Ha! I suppose it did.

But still, I think having the documentation be there for skipStateCheck would have been enough. I can't use cookies yet due to our setup, so will have to use some encrypted state anyway. The main reason it bugged me is it doesn't play nice with linting rules 😅

[panva]

I think having the documentation be there for skipStateCheck would have been enough.

It wouldn't. The entire premise of this discussion was that you assumed to have a valid reason to skip checking the state and the deprecation was getting in the way of using it, where in reality using smth along the lines of draft-bradley-oauth-jwt-encoded-state-09 is the only acceptable way skipping it and that's only because you'll have to validate it yourself (and frankly nobody implements that anyway). The deprecation did exactly as I hoped it would in this particular case.

FWIW if there was a better way of visually marking this as dangerous I would.

[ibrahimqasim-abtrace]

FWIW if there was a better way of visually marking this as dangerous I would.

I think that's all I was getting at. Since there's no other way to throw the warning in the users face, I can see your reasoning.

Thanks for all your help!