Since lesson 3.3.1, the Kladde’s database needs no password anymore. One secret remains that no identity can replace: the key the Kladde uses to sign the links in its booking emails. Anyone who knows this key can build a valid link for any booking. In this lesson it moves into a Key Vault, the app loads it at startup, and outside development the app doesn’t even start without it.

In K2, Data Protection protects the links in the booking emails (lesson 2.8.5, in the BookingLinks class since lesson 2.11.5). The app creates and manages the key ring for that itself. That’s right for cookies and forms, but not for a link in an email: The email sits with the recipient, outside the app, and the link in it has to stay valid even after the app has been restarted, moved to a new revision or, as in lesson 3.10.9, rebuilt from scratch. Data Protection also renews its keys by itself every 90 days. So the link gets a key of its own, one that you know, renew deliberately and can restore after an accident.

Container Apps takes care of the rest of Data Protection’s key ring, which sign-in and antiforgery use: For .NET apps delivered with Aspire, the environment stores it itself, so all replicas use the same one. Whether that applies to you is easy to see: Sign in, restart the revision, and reload the page. If you’re still signed in, the environment holds the key ring.