blob: c393be509337e65861bd9c88114fec02927e473e (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
"""Token audiences — one hub key, two purposes, never interchangeable.
The hub signs everything with one Ed25519 key, but a token has to say what it is
*for*, or a credential minted for one purpose is honoured for another. Two
audiences settle it:
- ``HUB_API_AUD`` — a session token, presented to the **hub API** (``hubFetch``,
signaling). Carried by the browser and the desktop client, and by a node for
its own hub calls.
- ``MNP_AUD`` — a short-lived token a member presents to a **node** in the MNP
handshake, and to nothing else. It authorises the member to that node
(``sub``, ``groups``, ``jti``) and is **useless at the hub API**.
The reason this exists: a member hands whatever token it holds to every node it
connects to (the handshake authenticates with it). If that were the session
token, a node operator — who is in the threat model — would hold a live hub
credential for the member and could act as them at the hub. Separating the
audiences means the credential a node receives opens nothing at the hub, and the
credential the hub API accepts is never disclosed to a node.
The hub API decode (:func:`meshbay_hub.auth.decode_access_token`) binds
``HUB_API_AUD``; the node handshake decode
(:func:`meshbay_common.handshake.authorize_token`) binds ``MNP_AUD``. Each
rejects the other's audience.
"""
HUB_API_AUD = "meshbay:hub-api"
MNP_AUD = "meshbay:mnp"
|