Hi Mario, On 17.03.26 12:06, Mario Loffredo wrote:
This is only true if the tokens are persisted. This must be true for opaque tokens, but is not true most of cases for rfc7523 JWT tokens. These tokens are self-carrying and only resource which can be exhausted is the token endpoint itself. A sane OAuth2 server will rate limit token generation per client to prevent that.However, the risk of managing too many sessions or maintaining unused sessions is common to all mechanisms based on server-generated secrets to prevent clients from authenticating on every request. To be clear, EoH sessions = RPP JWTs.The mitigation measures are the same: limit the number of simultaneously active secrets and optimize secret lifetime.
For http sessions is different, as usually some server-side resources are created to manage the session. There are solutions that carry the same properties as JWT tokens, where cookies are basically encrypted tokens with full state of the session (and nothing on the server), but I don't know how applicable it is to EoH. If the session state may change during the session, then strict ordering of the requests is required to prevent stale session cookie usage.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
