Token retention policy

[peppelinux]

@mdrew @melanger @c00kiemon5ter @nsklikas

I have to discuss with you about this topic, how satosa-oidcop handles the expired/refreshed token. At this time the expired will be pruned automatically if a mongo index for doing this is configured

the refreshed token instead will overwrite the old session.

This behaviour was implemented in here: https://github.com/UniversitaDellaCalabria/SATOSA-oidcop/blob/6539a23b3a447c1376968f6679be5776d4335143/satosa_oidcop/core/storage/mongo.py#L107

as you can see if you refresh a token, using this snippet for example https://oidcop.readthedocs.io/en/latest/contents/usage.html#refresh-token

the session will be overwritten. That looks good to me, why I should store an expired access_token?

But I admit that there would be some cases where an organization would store also the history. I don't know if a general configuration parameter would be a good compromise for this.

what do you think about?

[MdreW]

the history of authentications must go in the logs not in the database.... too much data is bad data

[c00kiemon5ter]

Is there a use case that requires to differentiate between different states of a token?

• revoked tokens
• expired tokens
• and unknown tokens

Would we need to know when a token expired and when it was removed? (different timepoints each event took place)

I guess the answers rely on the business, in relation to regulations (what would be good-enough for an auditor?)

[MdreW]

I think that can be useful know when an user has renewed a token for an incidents analysys and not for the authentication/authorization process.

If it's necessary to check a token I need to validate only the current token, the olders are history

[peppelinux]

@c00kiemon5ter

in the new/update method of the storage we can save/store/archiviate any historical information before (re)write the object. We may have to decide if this is a desidered feature and where to keep this information (in the db or in the logs)

any idea is appreciated

[MdreW]

thinking in a bored time.... if the problem is follow the token's history, we can add the session sid (or an UUID) in the OIDC log with necessary info.

With this trick the history is readable / seachable and the DB is not full, grep ${SID} satosa_oidc.log and you have a full user history.

[rohe]

I agree with @MdreW access tokens that for some reason (revoked/expired/...) are not usable anymore should not be in persistent storage. Putting enough information in the log to be able to later follow a token trail sounds good to me.

Whether the pruning is done by the library or by the persistent storage I don't really care.

We probably should provide one way of doing it in the library. This could be governed by configuration.