This PR is the following-up PR of https://github.com/tpitale/mail_room/pull/134. In the previous PR, I implemented JWT authentication support for postback strategy. The new authentication works well, but expose a potential attack vector such as replay attacks. A good way to prevent such attacks is to make token time-limited. JWT provides two ways of doing this via the claims:
exp: Expiration Time Claim. This claim controls the expiration of the token. It is the most straight-forward way. However, the expiration time is determined when the token is issued. It means the clients are a bit inflexible. We also need to add one more config.
iat: Issued At Claim. The timestamp when the token is issued is embedded into the payload. The clients examine the payload for the token age and act as their wills. As the limiting logic is delegated to the clients, we don't need a new config for expiration time.
This PR is the following-up PR of https://github.com/tpitale/mail_room/pull/134. In the previous PR, I implemented JWT authentication support for postback strategy. The new authentication works well, but expose a potential attack vector such as replay attacks. A good way to prevent such attacks is to make token time-limited. JWT provides two ways of doing this via the claims:
exp
: Expiration Time Claim. This claim controls the expiration of the token. It is the most straight-forward way. However, the expiration time is determined when the token is issued. It means the clients are a bit inflexible. We also need to add one more config.iat
: Issued At Claim. The timestamp when the token is issued is embedded into the payload. The clients examine the payload for the token age and act as their wills. As the limiting logic is delegated to the clients, we don't need a new config for expiration time.The second approach seems most reasonable.