motomac

После подключения JS SDK, который вы упомянули, вы можете получить информацию о юзере из Javascript, просто прочитав значение переменной `window.Telegram.WebApp`. Вернется вот такой объект. Если этот объект распарсить, в поле `user` будет объект юзера со всеми необходимыми полями.

Имейте ввиду, что юзер теоретически может подделать эти данные, т.к. они приходят из его браузера. Потому Телега подписывает все, что вам передает полем `hash`. Вам надо будет его проверить: https://core.telegram.org/bots/webapps#validating-...

По второму вопросу я бы не парился с поднятием собственного брокера и использовал какой-нибудь публичный. Например, www.mqtt-dashboard.com. Устройства подключаются к брокеру и пишут в один топик, ваш сайт/страничка подключается к тому же брокеру и подписывается на этот топик (MQTT over WebSocket). Для реализации этого можно использовать JS библиотеку https://www.npmjs.com/package/mqtt

В обратную сторону аналогично. Устройства подписываются на другой топик и слушают команды, отправленные в него с вашего сайта/страницы.

Самый минимальный набор знаний и технологий это Node.JS на бэкенде и любой JS фронтенд (хоть jQuery, хоть ванильный JS), работающие по WebSocket. Самый простой вариант реализации вебсокетов библиотека socket.io. Примеров тьма. Запилить минимальный чатик на этом можно за пару вечеров при условии знания JS.

Далее можно уже пилить хранение истории, регистрацию, например, добавив к бэкенду MongoDB или MySQL.

Делаем два метода аутентификации: Resource Owner Password Credentials Grant и Refresh token grant.

SPA отправляет логин/пароль юзера на первый endpoint. В ответ получаем access_token (например, JWT), refresh_token и expires_in. Сохраняем все это добро куда-нибудь, например, в Local Storage. Время жизни JWT-токена лучше ставить небольшое (например, 1 час), потому что отозвать его нельзя. Далее SPA при каждом запросе к API проверяет время жизни токена expires_in из Local Storage, и когда оно истекает, отправляет запрос на обновление токена (refresh_token). Все это прозрачно для юзера.

Stateless, по-моему, и проще, и универсальнее. Если потом делать, например, мобильное приложение, API переписывать не придется.

Вся фишка JWT по сути только в том, что не нужно дергать БД при каждом запросе к API. Делать это придется, например, только раз в час при refresh'е токена. Больше никаких существенных преимуществ перед традиционными токенами, хранящимися в БД, нет.

Советую курить именно официальный RFC по oAuth2, а не всякие блогпосты а-ля "OAuth2 простыми словами". Сам через это прошел. RFC - самый понятный и доходчивый источник знаний.