Ask for the permission, not the key: connect services safely
Copying the environment variable to the other server costs one line less. Asking the owning service for a signed link, which opens one screen and expires, removes a place where the key that opens every screen can leak. The criterion and the three rules behind it.
Also in: Español
You have two services of your own and one needs something from the other. The shortest path is to copy to the second one the environment variable the first uses to sign its access links. It costs one line less and adds one more place where the key that opens everyone's screen can leak.
The criterion: if the other service needs one specific access, let it ask for it and have it issued. The key that signs every access stays in one place.
A link is not a key
A signed link opens one screen and expires. The key that signs it opens everyone's and does not expire. If the service that receives it is compromised, or the variable shows up in a log or a backup, the damage from a link is one screen for a while. The damage from the key is every screen, until someone rotates it.
Three rules for the route that issues
A server publishes proposals for clients and needs to link each project's screen in a portal. Instead of taking the portal's secret, it asks an issuing route for the link.
- It only signs what it already knows. Without that filter it would be a generic signer: whoever held the credential could fabricate the entry to any screen.
- Its own credential. It uses a dedicated credential, separate from the query token each project's assistant holds. With a single one, a compromised assistant could issue access to any client's screen.
- The expiry is capped, not rejected. An eternal link inside a document that gets forwarded would be a permanent access; and rejecting the request would leave the salesperson with nothing to send.
Pin it down in tests
A security rule that lives only in its author's head is lost in the next refactor. Two tests matter more than the rest: the issued link is accepted by the same verifier the door uses, and one project's link does not open the neighbor's.
Before you apply it
Count how many machines hold the token you plan to reuse today, and ask yourself whether you would give all of them the new capability. If not, that capability needs its own credential.
Write to us with what your business does, and we will build this on your material.