I would like to use an asymmetric rather than symmetric signature for authorization, since I don't want a compromised service being able to forge authorization tokens (obviously). An authorization token is generated by an authentication server for a specific set of services, and returned to the client, always transported as a base64 encoded string. After expiry, the principal must re-authenticate to retrieve a fresh token.
I need to handle a high volume of very small stateless HTTP-REST requests (potentially several a second per client), and I'm conscious of the overall size of the token saturating the network. Currently I'm (randomly) considering using 2048-bit RSA with SHA-256, but further reducing this overhead would be great.
Since a given token will always expire within at most 15 minutes, it dawned on me that it should be possible to use an even smaller key/hash by regularly generating new key-pairs.
Services would periodically poll a key provider service to retrieve the current and next public key, and a byte or so of the token would identify the key used to sign it.
Is my assumption correct? Can I stoop to as low as 1024-bit keys? I vaguely recall that there is a break for RSA <= 512 bits, how severe is it, and could one compensate by rotating the keypairs faster?
I'm not married to either RSA or SHA256, but I am dependent on OpenSSL.
I'd like to first ensure my reasoning is sound, and second, to solicit any algorithm/key-sizes/alternative techniques that would be considered good practice in this situation.