Module cron: what is it for and how frequently should it run?

Created on 25 July 2025, 6 days ago

Problem/Motivation

We are using Ultimate cron to optimize cron job frequencies, and for this module I find it hard to deduce of frequent it should run.

I can read the cron job is to check and update 'JSON web keys' that are stored in key_value storage, thus without expiration.
This indicates to me that these values aren't time critical, but after inspection of actual records I'm not so sure.

So, can be explained what the purpose of these records are, and what recommend cron frequency is to have them checked/updated?

We don't want to make unnecessary calls to remote APIs, to save some unnecessary load on both (we have already a long list of cronjobs) our end as the API.

Proposed resolution

Add some info, recommendation to the module README.

💬 Support request
Status

Active

Version

2.3

Component

Documentation

Created by

🇧🇪Belgium andreasderijcke Antwerpen / Gent

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @andreasderijcke
  • 🇧🇪Belgium matthijs

    Hi,

    I'd say that twice or even once a day is fine.

    The cronjob is indeed used to update the stored JSON web keys (which are used to verify the incoming OpenID Connect request).
    But the validation code also contains a fallback, when an unknown key ID is specified it automatically updates they key set to make sure it ain't a new key.

    The main reason to keep the cron is to also remove any revoked keys, so it's up to you to decide what "risk" (accepting a revoked key) you are willing to take.

    Hope this helps a bit?

  • 🇧🇪Belgium andreasderijcke Antwerpen / Gent

    Thanks for the fast response!

    One follow-up question though: What would a 'revoked key' imply for this case. A person that lost its citizenship?

  • 🇧🇪Belgium matthijs

    These are server keys, not user keys. If somehow the private key of an OpenID server leaks they can revoke it, otherwise a malicious provider would be able to sign the authentication data with the leaked key and thus forge sign-ins.

  • 🇧🇪Belgium andreasderijcke Antwerpen / Gent

    Ah, clear. Thanks!

Production build 0.71.5 2024