This document discusses using bearer JWT tokens for authorization in distributed systems without a central authority. It motivates this approach by describing requirements for decentralization, privacy, and reducing complexity. It then explains how bearer tokens work by containing a signature, claims about permissions, and how verification is done to apply permissions to ephemeral users. Finally it discusses some caveats, examples of usage, and resources for further information.

1. D i s t r i b u t e d
Identity & Authorization
The case for bearer tokens in .
Kyle Thomas
Founder & CEO

2. Motivations
- Distributed peer-to-peer messaging fabric
- Decentralization
- Privacy management
- Secure messaging
- Reducing complexity and cost
- Next-gen business process automation readiness
- Point-to-point enterprise data transfer

3. Requirements
- No central authority or broker
- Delegated authorization to self-sovereign organizations
- Ephemeral user model (in-memory for the duration of a connection)
- RS256 & Ed25519 signing algorithm support
- No dependency on nsc for generating key material
- Zero required configuration of operators, accounts or users

4. Bearer JWT
- Ubiquitous & extensible
- Token anatomy: header, payload & signature
- exp header contains the expiration timestamp of the bearer authorization
- alg header indicates the algorithm used for signing (EdDSA or RS256)
- kid “key id” header contains a identifier indicating which public key
should be used for signature verification
- nats permissions claim contains publish, subscribe and
allow_responses resource authorizations
- signature verification is attempted on CONNECT; if successful,
permissions are applied to an ephemeral in-memory user

5. Permission Model
{
"publish": {
"allow": [
"foo.bar",
"foo.*.baz"
],
"deny": []
},
"subscribe": {
"allow": [
"foo.bar”
],
"deny": []
},
"allow_responses": true
}

6. Permission Model{
"aud": "nats://nats.provide.network",
"exp": 1586804105,
"iat": 1586717705,
"iss": "https://ident.provide.services",
"jti": "d22768b8-10e5-411b-8840-caa438cc0cd9",
"nats": {
"permissions": {
"subscribe": {
"allow": [
"user.e889edea-580f-40d8-addf-d509dcf7783a",
"network.*.status",
"platform.>"
]
}
}
},
"prvd": {
"permissions": 7553,
"user_id": "e889edea-580f-40d8-addf-d509dcf7783a"
},
"sub": "user:e889edea-580f-40d8-addf-d509dcf7783a"
}

7. Caveats
- How do other configured authorization schemes work when JWT bearer
authorization is enabled?
- Disable the other schemes!
- Support -auth token parameter as fallback while migrating (i.e., NATS
Streaming example)

8. Usage
➜ ~ JWT_SIGNER_PUBLIC_KEY='
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAullT/WoZnxecxKwQFlwE
9lpQrekSD+txCgtb9T3JvvX/YkZTYkerf0rssQtrwkBlDQtm2cB5mHlRt4lRDKQy
EA2qNJGM1Yu379abVObQ9ZXI2q7jTBZzL/Yl9AgUKlDIAXYFVfJ8XWVTi0l32Vsx
tJSd97hiRXO+RqQu5UEr3jJ5tL73iNLp5BitRBwa4KbDCbicWKfSH5hK5DM75EyM
R/SzR3oCLPFNLs+fyc7zH98S1atglbelkZsMk/mSIKJJl1fZFVCUxA+8CaPiKbpD
QLpzydqyrk/y275aSU/tFHidoewvtWorNyFWRnefoWOsJFlfq1crgMu2YHTMBVtU
SJ+4MS5D9fuk0queOqsVUgT7BVRSFHgDH7IpBZ8s9WRrpE6XOE+feTUyyWMjkVgn
gLm5RSbHpB8Wt/Wssy3VMPV3T5uojPvX+ITmf1utz0y41gU+iZ/YFKeNN8WysLxX
AP3Bbgo+zNLfpcrH1Y27WGBWPtHtzqiafhdfX6LQ3/zXXlNuruagjUohXaMltH+S
K8zK4j7n+BYl+7y1dzOQw4CadsDi5whgNcg2QUxuTlW+TQ5VBvdUl9wpTSygD88H
xH2b0OBcVjYsgRnQ9OZpQ+kIPaFhaWChnfEArCmhrOEgOnhfkr6YGDHFenfT3/RA
PUl1cxrvY7BHh4obNa6Bf8ECAwEAAQ==
-----END PUBLIC KEY-----' ./nats-server -p 4222 -DV [-auth natstoken]
➜ ~ docker run -e JWT_SIGNER_PUBLIC_KEY=$PUBKEY provide/nats-server
or

9. Use in production
Coming soon...
Ekho ProtocolShuttleby Provide

10. Resources
- NATS Server PR #1149
- NATS Server fork on GitHub and DockerHub
- ts-natsutil library with nats:// and wss:// support on GitHub
- Get in touch:
Twitter: @kylebt
GitHub: kthomas