[package]
name = "swarm-nats-auth"
version.workspace = true
readme = "README.md"
edition.workspace = true

[[bin]]
name = "swarm-nats-auth"
path = "src/main.rs"

[dependencies]
anyhow.workspace = true
async-nats.workspace = true
clap.workspace = true
# base64url for decoding the inbound request JWT.
data-encoding.workspace = true
# StreamExt::next on the subscription: async-nats returns a Stream.
futures-util.workspace = true
nkeys.workspace = true
reqwest.workspace = true
serde.workspace = true
serde_json.workspace = true
# The jti digest: base32hex(sha256(claims)) over every JWT this crate signs.
sha2.workspace = true
# For `status::BUCKET` alone - the subjects a hive may publish to are derived
# from the bucket name, and the reader, the writer and this responder must
# name the same one. Deliberately WITHOUT the `kv` feature: this crate derives
# subject strings, it never opens the bucket.
swarm-queue-client.workspace = true
tokio.workspace = true
tracing.workspace = true
tracing-subscriber.workspace = true

[dev-dependencies]
# A TEST ORACLE, not part of the production path. Neither JWT this crate emits
# is expressible through it - `Claims` has no `aud`, which the response wrapper
# needs (the server id) and the user token needs (the account name), and
# `Token::new_user` always sets `issuer_account`, which a non-operator server
# rejects outright. So both are hand-built, and this crate is what the encoder
# is checked *against*: `respond::tests::hand_built_matches_the_reference`
# builds a user token both ways and requires byte equality, on the one shape
# nats-jwt does model.
nats-jwt.workspace = true

[lints]
workspace = true