Guardian.Plug.Keys (Guardian v2.5.0)

Calculates keys for use with plug.

The keys relate to where in the session/connection the data that Guardian deals in will be stored.

token, claims, resource are all keyed. token, claims, resource are all stored on the conn. token is stored in the session if a session is found.

Atom safety

A Guardian "key" names a namespace on the connection. Because these keys are ultimately used as atoms (Plug.Conn private storage is atom-keyed), turning an arbitrary binary into an atom would let attacker-influenced input (a tenant id, a header, ...) create unbounded, never-collected atoms and exhaust the BEAM atom table (GHSA-xqch-c77q-rgh5 / CVE-2026-54894).

To stay safe the lookup helpers (token_key/1, claims_key/1, resource_key/1, base_key/1) never create atoms from binaries: they resolve through String.to_existing_atom/1 and return nil when the atom does not exist, which reads back as "nothing stored under this namespace". New namespace atoms are only ever created through the write-only bang helpers (token_key!/1, claims_key!/1, resource_key!/1), whose key comes from developer configuration rather than request data. Session and cookie names use the string helpers (token_key_string/1, ...) and need no atom at all.

key_from_other/1 recovers the base key from a namespace that is already stored on the connection. String-keyed setups intern only the suffixed atoms (e.g. :guardian_acme_token, never :acme), so when the bare atom does not exist the key is returned as a string rather than dropped - sign_out(:all) must still find those namespaces. All key helpers accept any term that implements String.Chars (atoms, binaries, integers, ...).