# jose / Node API на Linux

Этот архив — воспроизводимая лаборатория. Не превращайте /demo-token в открытый issuer для рабочего приложения. Для рабочего приложения нужны существующий механизм входа, управляемое хранение подписывающих ключей, политика отзывов, разграничение токенов и проверка доступа к конкретному объекту. Библиотека не решает эти задачи вместо приложения.

## Локальный сервер и SSH

Установите Node 24 LTS, создайте отдельный каталог проекта и выполните npm ci без root. API слушает loopback: 127.0.0.1:8523. Для просмотра с рабочей машины можно поднять свой SSH-туннель:

```bash
ssh -L 8523:127.0.0.1:8523 user@your-vps
```

Не открывайте 8523 в firewall для этой лаборатории. Статическую мастерскую public публикуйте отдельно по HTTPS. Там нет серверного генератора токенов и приватного материала; ключи для интерактивного опыта создаются в памяти браузера.

## Пример systemd только для закрытого учебного API

Код /opt/jose-lab. Сначала создайте отдельного пользователя и проверьте путь node командой command -v node. Установленные через личный nvm бинарники не следует случайно использовать от другой учётной записи.

```ini
[Unit]
Description=Private loopback jose teaching API
After=network.target
[Service]
Type=simple
User=jose-lab
Group=jose-lab
WorkingDirectory=/opt/jose-lab
ExecStart=/usr/bin/node src/api-cli.mjs
Environment=NODE_ENV=production
Restart=on-failure
RestartSec=3
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
UMask=0077
[Install]
WantedBy=multi-user.target
```

Environment NODE_ENV не превращает демо в рабочую авторизацию. Она лишь обычная настройка сервиса Node.js. Реальные ключи в этом примере не подключаются. После каждого рестарта память и пары заменяются, поэтому прежние подписи не пройдут.

```bash
sudo systemctl daemon-reload
sudo systemctl start jose-lab
curl -fsS http://127.0.0.1:8523/health
sudo journalctl -u jose-lab -n 30 --no-pager
# Остановить только эту лабораторию:
sudo systemctl stop jose-lab
```

Для постоянного API рабочего приложения сначала удалите /demo-token, подключите проверенный issuer/JWKS по заранее заданному HTTPS-адресу и отдельную серверную политику scopes/объектных прав. Не выбирайте URL из jku или ключ из входного токена как новый доверенный источник. Запретите логи Authorization; возвращайте клиенту короткую ошибку, а диагностику сохраняйте без полного JWT. Reverse proxy с HTTPS и политика авторизации должны быть проверены отдельно.

## Ротация

Сначала публикуют новый публичный ключ B в доверенном наборе вместе с A. После обновления проверяющих сервисов начинают подписывать B; A оставляют на период жизни старых токенов и согласованной погрешности. Затем A убирают. Это плановая ротация. Компрометация требует отдельного аварийного порядка, учитывающего кэши и отзыв доступа. Лаборатория использует createLocalJWKSet, поэтому не тестирует сетевой кэш/таймауты createRemoteJWKSet.

Проверки Linux архива выполняются в изолированном контейнере; команды службы и внешнего TLS приведены как применяемый шаблон, не как отчёт о развёртывании вашего VPS.