Thank you @stefanzweifel! That confirms my understanding. Per the lcobucci/jwt v3.2 documentation under “Token signature>Hmac” I have implemented token expiration with the following modifications in bold:
$token = (new Builder())
->setIssuedAt(time()) // Configures the time that the token was issue (iat claim)
->setNotBefore(time() + 60) // Configures the time that the token can be used (nbf claim)
->setExpiration(time() + 3600) // Configures the expiration time of the token (exp claim)
‘dashboard’ => 1 // ID of the dashboard you want to implement
‘params’ =>  // Corresponds to Metabase locked parameters
Although a significant deterrent to would-be unauthorized access it is, as you’ve noted, not a totally satisfactory solution.
For one it is not advisable to set the expiration time to something too short because upon expiration the embed’s Metabase filters become disabled and the entire embed disappears returning a token expired message. On the other hand setting the expiration even to something reasonable like 1 hour as shown here (3600 seconds) can still be annoying (imagine users in the middle of a conference presentation or a big board meeting and the expiration surprise suddenly scuttles the whole thing)! While I like the idea of Sliding Sessions to get past this I’m not so keen on the Refresh Tokens requirement behind them or the ways of tweaking them as pointed out by lcobucci/jwt’s creator.
For another even with an expiration time of one hour that’s one hour any determined party can gain unauthorized access. Metabase’s powerful locked parameters feature can be used to provide user specific content provided the user or group of users is a filterable category in the data itself. But that is not intended as a security guarantee, any one of a group of users could share a token-ized url with parties outside the group.
The only way around this is to lock certain key parameters thereby removing them from the iframe entirely (e.g. products and geography) to vastly limit access. But that means one’s app must feed these in directly via a dropdown completely outside of Metabase, for example. And that may be burdensome not to mention annoying for legitimate users if it implies having to constantly refresh and reload the iframe and loose all previously set Metabase filters.
Providing each of the app’s users with a unique key that is revoked when accessed by more than one party simultaneously, more than a couple of devices, or something of that nature may work. But I’m afraid I haven’t even the vocabulary to start researching such a thing.
So for the time being, expiring tokens will just have to do.