feat(backend): periodically clean up expired rows

[dclipp]

Changes proposed in this pull request

• add logic to auth to periodically delete database rows that we consider "expired"
• add rule for cleaning up accessTokens table

Context

fixes #385

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Documentation added
• Make sure that all checks pass

[wilsonianb]

Should this be configurable?

[dclipp]

I thought 10 minutes was reasonable but it's not actually part of the spec. I can just hardcode it if you think that's cleaner, though.

[wilsonianb]

I'm not sure this default is actually necessary.
We currently only have databaseCleanupRules for accessTokens, for which expiresIn is nullable but we appear to always define it.

I vote we make expiresIn non-nullable and remove accessTokenMinDaysBeforeDeletion

[njlie]

I second the above ☝️

[dclipp]

I could remove accessTokenMinDaysBeforeDeletion and make expiresIn non-nullable, but it seems like the spec recommends against removing expired tokens immediately:

Note that in many cases, the access token will have expired for regular use. To facilitate token rotation, the AS SHOULD honor the rotation request of the expired access token since it is likely that the client instance is attempting to refresh the expired token.

That makes me think that we'd still need to define a constant somewhere to prevent the auth service from cleaning up tokens before the client has a chance to request renewal of an expired token.

Maybe it doesn't need to be configurable, though. Let me know what you think

[wilsonianb]

Got it. Good point.
How about a configurable accessTokenDeletionDays that processDatabaseCleanup uses?
An access token would be deleted if (createdAt + expiresIn +accessTokenDeletionDays) < now.

Should the old access token always be deleted (expired or otherwise) by token rotation?

[dclipp]

Yeah, right now the old token is deleted during rotation (see #335 / #375)