How to overcome limitations of itsdangerous for SSO: encryption and expired tokens

Question

I have built several related applications using Python and Flask. One is an authentication app where the user logs in and receives a token. The others are business apps, which authenticate and authorize the user based on the token. Of course it's necessary to sign the token to prevent tampering. Since I'm using Python, the itsdangerous module is a natural choice. But it doesn't provide some features that seem important. Writing one's own security code is rarely a good idea, but I feel forced to add my own code on top of itsdangerous to address some limitations. I'd like to know:

a. Are the concerns below valid? b. If so, can anyone recommend a good open-source security solution for Python/Flask that addresses them?

The two limitations that most concern me are:

1. Lack of encryption. Itsdangerous can sign the token but can't encrypt it. The token might contain information the user shouldn't see, such as a list of which roles he or she has been granted.

2. Leaking information about whether an expired token was ever valid. A malicious user who got hold of a token could use itsdangerous to differentiate between tokens that were never valid, and tokens that used to be valid but have expired. It would be better if such a user could tell only that the token is invalid, with no indication as to why.

Answer 1

1. Lack of encryption. Itsdangerous can sign the token but can't encrypt it. The token might contain information the user shouldn't see, such as a list of which roles he or she has been granted.

I don't see the harm in letting a user see what roles he's been grated. But if you don't want that visible in the token, you could simply treat the token as an identifier and establish a relationship between the token and the user and consequently the user's roles.

If the token truly contains private data, then you should encrypt it first (e.g., using PyCrypto), and then sign it (e.g., using itsdangerous or hmac).

See Should we MAC-then-encrypt or encrypt-then-MAC? for information about the order of signing and encrypting data.

2. Leaking information about whether an expired token was ever valid. A malicious user who got hold of a token could use itsdangerous to differentiate between tokens that were never valid, and tokens that used to be valid but have expired. It would be better if such a user could tell only that the token is invalid, with no indication as to why.

If you encrypt the token, or if the token is simply an identifier, then a malicious user should only be able to tell if the token is currently valid (i.e., it works right now) but not whether any other token would be valid without directly using it. But why would knowing ahead of time whether a token is valid or not affect security?