Concurrent requests for token endpoint on auth-code flow with same code succeed. about fosite

[tn185075]

Bump ‼️ ‼️

[vivshankar]

Won't this depend on the storage implementation? In my implementation, we use redis for such short term storage and treat the Get as a pop. The choice of storage doesn't matter too much.

I expect that is the only way to atomically implement this.

[james-d-elliott]

There are quite a few options in Postgres to deal with this from memory.

[mitar]

I think you need at least repeatable read isolation levels, but you can just go with serializable.

[vivshankar]

@tn185075 are you concerned about the implementation in fosite that uses the memory store? At the moment, the InvalidateAuthorizeCodeSession is a no-op for me. I expect in any practical implementation, that would be the case. The GetAuthorizeCodeSession should pop, i.e. get and delete atomically.

I haven't looked at Hydra.

[tn185075]

popping it out on GET is a probable solution, but has it's own limitations. As we need to keep that record, in case if we fail to reach the populateTokenEndpointResponse, client should be able to use the auth code again to fetch the token.

Also it's one of the key info, which we can use to detect malicious activities against our providers I believe.

I do not think it is a storage problem, as we are making a get in HandletokenEndpointRequest, but invalidation happens in PopulateTokenEndpointResponse. This is a clear case of race/timing conditions, in my opinion, even if we manage to wrap the block invalidating auth code over mutex :).

[tn185075]

If I remember rightly, I believe I was able to replicate this with Hydra :).

[tn185075]

Any updates here? ‼️