После обсуждения с моим коллегой @owengot вот более подробное описание проблемы.
Существует веб-приложение на базе Vue.js, у которого нет собственного активного серверного компонента. Это автономное веб-приложение, использующее API Discourse, то есть в некотором роде сервером выступает сам Discourse. Примеры использования: автономные опросы или формы, где контент публикуется в темы Discourse от имени пользователя. Возможность создавать такое программное обеспечение без кастомных серверных компонентов казалась привлекательной архитектурой для таких задач, поэтому в идеале мы хотели бы избежать любой работы «на стороне сервера».
Теперь о том, как получить ключ User-API: это работает как задумано, но @owengot обнаружил, что этап генерации закрытого ключа в JavaScript занимает много времени (до 10 секунд, это просто неэффективно в JavaScript…). Затем он нашёл обходной путь: один и тот же закрытый ключ можно использовать для нескольких пользователей, поэтому он сохранил его в файл на веб-хостинге, который также обслуживает другие статические файлы веб-приложения (JS, CSS и т. д.). Это ускорило процесс… но теперь этот закрытый ключ (1) является общим и (2) хранится в открытом виде, по общедоступному URL. Это, э-э, пугает 
Поэтому я сказал, что нам нужно спросить команду Discourse о последствиях для безопасности этого обходного пути. Я вижу два основных варианта:
-
Если этот закрытый ключ используется «только» для шифрования полезной нагрузки, то мы можем с этим смириться, поскольку наше взаимодействие также защищено шифрованием SSL/HTTPS.
-
Но если знание этого закрытого ключа каким-либо образом позволяет вычислить результирующий ключ User-API, который затем используется для публикации от имени чьей-то учётной записи в Discourse, то такой обходной путь, конечно же, станет неприемлемым.