I came up with this technique when designing our platform (https://qbix.com/platform) so I don't know if it's widely used.
Many apps include session id tokens in requests, to identify the logged-in user. The session id is usually a bearer token (like in a cookie) which identifies the session on the server.
To mitigate against DDOS attacks, as you said, all publicly available resources can be cached on CloudFlare. (Personally I look forward to content-addressable protocols like IPFS supplanting HTTP.)
However, the non-public resources are usually dynamic and should not be cached. These resources are typically for users who have logged in, or at least have a session.
So our design basically encourages this:
1) if you want to serve non cacheable resources, require that the request included a session id
2) the session id is generated on our server and signed with an HMAC so the app can verify this signature without doing any I/O.
This is because I/O is expensive and hard to parallelize, whereas statelessly checking whether a session token has been issued by our app is easy to implement, even at the external router level. Simply examine the packets coming in, decrypt, look at the request, and verify the HMAC on the session id. If it is wrong then the session id is bogus so we don't expend any more resources within the network on this request.
You can make sessions expensive to start. For example, a user might have to log in with a valid account to get a session.
The big question is, how can we ensure that users don't get too many accounts? To prevent sybil attacks. Any ideas?
Many apps include session id tokens in requests, to identify the logged-in user. The session id is usually a bearer token (like in a cookie) which identifies the session on the server.
To mitigate against DDOS attacks, as you said, all publicly available resources can be cached on CloudFlare. (Personally I look forward to content-addressable protocols like IPFS supplanting HTTP.)
However, the non-public resources are usually dynamic and should not be cached. These resources are typically for users who have logged in, or at least have a session.
So our design basically encourages this:
1) if you want to serve non cacheable resources, require that the request included a session id
2) the session id is generated on our server and signed with an HMAC so the app can verify this signature without doing any I/O.
This is because I/O is expensive and hard to parallelize, whereas statelessly checking whether a session token has been issued by our app is easy to implement, even at the external router level. Simply examine the packets coming in, decrypt, look at the request, and verify the HMAC on the session id. If it is wrong then the session id is bogus so we don't expend any more resources within the network on this request.
You can make sessions expensive to start. For example, a user might have to log in with a valid account to get a session.
The big question is, how can we ensure that users don't get too many accounts? To prevent sybil attacks. Any ideas?