Decisions

Why is the login its own plugin?

Your relay login is used by tunnels, boxes and share links, and none of them owns it. In the tunnel plugin, making boxes would mean installing tunnels, and removing tunnels would lose the login boxes need. Link's test for a seam is whether you'd still use the code without the plugin it sits in; the login fails it in any plugin but its own. So the accounts plugin keeps the login and its file, and the others ask lnk auth ... --json for what they need from it (contracts).

Why does the tunnel get the login token itself?

A tunnel connects to the relay with the login token, so it needs the token, not a short-lived one. It asks lnk auth relay --json rather than reading the file, so the file and its Keychain item stay the accounts plugin's alone. The token reaches only a process of the same user, who can read the file already.

Why does a new login wait for a machine already signed in?

The relay's approval page shows who is logging in, from where, and warns about another network, but a person can still be talked into approving. A machine already signed in is something a phisher doesn't have: once an account has one, a login approved in the browser waits for it too (lnk auth approve), shown the same device, address and code. Tricking someone then takes two approvals, in two places, and the second one says where the login came from. An account's first login has no machine to ask, so it is the browser's alone, as before.

Any of the account's machines can confirm, not one chosen as the "main" one: a person signed in on a laptop and a desktop shouldn't need a particular one at hand. The new machine names a few of them, so you know where to look.

Why does lnk auth approve deny when you answer no?

A login you didn't start is the reason to look, so the answer that isn't yes ends it: the new machine is told it was denied, and on which machine. One you did start costs only another lnk auth login. Given a code (lnk auth approve <code>), it confirms that one without asking: typing the code is the comparison the question asks for.

How does a box sign in without asking you twice?

lnk box start runs lnk auth login on the box while you watch, and this machine is signed in already. It asks the relay for a ticket (lnk auth ticket --json), a confirmation given ahead, and hands it to the box's login. Once you approve that login in the browser as the same account, it needs nothing more. A ticket works once, for 10 minutes, and only for its own account; by itself it gets no token, since the browser's approval is still needed. A machine logging in again, still holding its token, confirms its own login the same way. Matching the box by its address or name instead would let someone else's login started at the same moment pass as the box's.

What does an older lnk get?

It can't show a confirmation step, so a relay that needs one refuses it when the browser's approval comes in, and the approval page says the same: upgrade, log in again, confirm with lnk auth approve. Leaving it waiting would look like a hang. Where no machine is signed in, it logs in as it always did. A new lnk says it can wait (confirm in its start), which is how the relay tells them apart.

How does someone who lost every machine get back in?

Through the operator: link-relay admin logout <user> revokes all of the account's login tokens, and its next login needs only the browser. Anything a person could do alone from a new machine, a phisher could too.