2017-02-19

Об UI

Забыли про механические компьютеры. Они могли только числа молотить. Поэтому весь интерфейс у них — это ввести числа колёсиками, да покрутить ручку, чтобы результат получить. Весьма неплохой интерфейс для этой задачи, кстати.
Арифмометр
У первых электрических (но ещё не электронных) компьютеров интерфейс был прост. Надо было нужные кабели повтыкать в нужные дырочки. Ну примерно как на первых телефонных станциях. «Барышня, соедините меня...» Барышня и соединяет. Буквально, проводом.
Коммутатор
Перетыкание проводов быстренько заменили переключателями: тумблерами или поворотными. Ну и лампочки, конечно, как устроство вывода.
Потом наступила эпоха перфокарт и перфолент. Машина их ела и мигала лампочками в ответ. Сразу стало понятно, что дырявить эти дырочки вручную — гиблое дело (впрочем, наверняка всякое бывало). А печатные машинки, да и телеграф, уже тогда были. Ну и были телетайпы. Эти вполне себе клавиатуры тут же приспособили сначала для пробивания перфолент/карт, а потом и для непосредственного ввода данных уже в электронные компьютеры.
Те же телетайпы были ещё и принтерами. И компьютеры научились на них печатать. Вводим буковки, получаем буковки. Уже хорошо.
Телетайп
Что ещё осталось? Да, чтобы не тратить тонны бумаги, придумали подключать к компьютеру ЭЛТ экраны. Забавно, что в некоторых древних компьютерах ЭЛТ использовались как память (люминофор продолжает какое-то время светиться после облучения электронами). И уже тогда энтузиасты начали писать компьютерные игрушки, рисующие что-нибудь на этих ЭЛТ.
Клавиатура есть. Экран есть. Рисовать компьютеры пока могут только буковки. Но и этого достаточно. А ещё компьютеры были довольно дорогие и большие. Поэтому пользовались ими сразу несколько человек. Часто даже удалённо, через те же телетайпы. Это даже называлось многопользовательскими многотерминальными системами. Но у каждого человека была своя оболочка, принимающая его команды. Это был Unix. И это был интерфейс командной строки (короче говоря, CLI).
CLI on Apple
CLI, как вы знаете, до сих пор жив и процветает. Потому что ничто не может превзойти его по эффективности использования канала связи с удалённой машиной. Поэтому удалённое администрирование — это только CLI. За редким исключением дурацких Windows серверов.
CLI хорош, но требует серьёзной предварительной подготовки пользователя. Нужно знать, какие команды есть, что они делают, какие аргументы и в какой форме принимают. Прежде чем начать пользоваться, нужно это всё изучить. На уровне концепций и способов манипуляций с ними. Не зная, что такое файловая система и каталоги, невозможно понять, что делает команда cd.
Хотелось чего-то более очевидного, наглядного и интуитивно понятного. Поэтому понятен бешенный успех того же Norton Commander. Технически это всё тот же текстовый интерфейс. Но визуально это что-то совсем другое. Это что-то, что наглядно представляет предметную область, в данном случае файлы.
Norton Commander
Это что-то называется графическим (в случае Нортона — псевдографическим) пользовательским интерфейсом (он же GUI).
Графика, т.е. возможность отображать компьютером не только буковки, но и любое изображение, была очень важна. Те же ребята, что на малюсеньких круглых ЭЛТ первых компьютеров делали игрушки про полёты в космос, делали для этих же компьютеров и программы проектирования инженерных сооружений и расчёта их прочности. То, что позднее превратилось в целый класс ПО — CAD. Тут без графики ну просто совсем никак.
Sketchpad
А ребята из Xerox в 70-е годы прошлого века баловства ради решили, что нарисовать можно не только балки и мосты, но обычные вещи, вроде рабочего стола (буквально, стола), папочек, листиков с документами и всё такое. На их беду к ним в гости зашёл некто Стив Джобс. И компьютеры фирмы Apple чуть ли не с самого начала имели GUI в качестве основного интерфейса взаимодействия с пользователем. PC с MS-DOS на этом фоне смотрелся бледновато. Microsoft со своими Windows подтянулись заметно позднее.
Xerox Alto
Что нам даёт GUI? Наглядность. Понятность. Возможность протыкать всё, что есть (меню), не запоминая заранее. Для простого смертного пользователя требуется гораздо меньше предварительной подготовки. Конечно, появились свои примитивы, которым всё же нужно учить. Окна, поля ввода, кнопки, меню. Надо же понимать, что в эти нарисованные прямоугольники можно тыкать.
Кстати, тыкать. GUI подарил нам указательное устройство. Как ни удивительно, вначале это было световое перо (или пистолет). Такая штуковина, которую нужно было наводить на экран. Но прижилась всё же мышка. Хоть она и привязана к конкретным координатам экрана только посредством указателя, и сам по себе манипулятор никаких координат не выдаёт.
Световое перо
Экран, клавиатура, мышка. Окна, меню, кнопки. Что дальше? Дальше случился Web (он же WWW).
До Веба всё взаимодействие в Интернете было исключительно текстовым. Та же электропочта, Gopher... Веб тоже задумывался текстовым, но почти сразу же для него появился графический браузер — Mosaic. Ну и быстренько научились в HTML документы вставлять картинки.
NCSA Mosaic
Никто тогда не думал, что под Веб можно создавать приложения. Ну да, появились формы. Да, появились какие-то интерфейсы. Но строились они исключительно по принципу запрос-ответ. Просим пользователя заполнить форму, отображаем результат. Никакого интерактива и мгновенных изменений, никакой анимации, в конце концов. Как оно уже всё было в десктопных приложениях, в Вебе ничего такого не было.
А потом появился JavaScript. Сначала просто анимация, изменение страницы без перезагрузки. Потом докатились до Single Page Application. Браузеры посолидней стали. Железо десктопное подтянулось. И оказалось, что Web UI вполне может тягаться с десктопным GUI. И даже имеет некоторые преимущества. Браузер уже есть в каждой приличной системе, и приложение не нужно устанавливать. И обновляться оно будет само. И к облакам-серверам будет обращаться вполне естественным способом, через тот же HTTP.
Дошло до того, что появилась даже Chrome OS — операционная система, в которой есть только браузер и веб приложения.
Chrome OS
Сейчас веб UI почти не уступает дестопному UI. Анимация, свестелки, перделки, даже 3D, всё есть. Десктоп ещё не умер окончательно, пожалуй, только по двум причинам. Веб приложениям всё ещё нужен Интернет, чтобы полноценно работать. Веб приложения потребляют значительно больше ресурсов, чем аналогичные по функциональности десктопные приложения.
Дошло уже до того, что стали лениться делать нормальные десктопные приложения, а стали просто делать запускалку с WebView. А внутри этого WebView запускать те же самые веб приложения. JavaScript повсюду, JavaScript везде, даже на серверах. Ужас какой.
Electron
Однако, с веб приложениями началась интересная тенденция. Упрощения. Десктопные приложения можно было делать узкоспециализированными, продавать конкретной аудитории, с которой можно брать деньги за обучение. В вебе аудитория потенциально не ограничена. Прийти и запустить ваше приложение может кто угодно. И надо бы, чтобы этот кто угодно не развернулся в ужасе, а проникся любовью и уважением к вашему продукту. Заработал маркетинг, начали всерьёз интересоваться пользователем. И оказалось, что кучи настроек и возможностей не нужны всем. Всем нужно, чтобы было просто и красиво. И интерфейсы стали проще и понятнее. А приложения часто стали менее функциональными.
Your company app
Однако, действительно сложные приложения, с действительно сложным и нагруженным интерфейсом, всё ещё проще делать для десктопов. Поэтому серьёзные IDE пока существуют только для десктопа. А ещё IDE требуют заметных ресурсов, и дополнительные накладные расходы веба тут совсем не к месту. Так что пока что десктоп жив.
Jobs and iPhone
Благодаря тому же Стиву Джобсу у нас сейчас появился ещё один тип пользовательского интерфейса. Мобильный.
Вроде тот же GUI, но не совсем. Во-первых, очень очень очень маленький экран. Не по пикселям, а по физическим размерам. Во-вторых, экран сенсорный. Вместо, как внезапно оказалось, очень точной мыши, у нас толстый пользовательский палец.
Маленький экран очень сильно ограничивает сложность интерфейса. На него просто не помещается много элементов управления. Нужно ещё сильнее упрощать. Управление пальцами добавляет некоторые неожиданные возможности, вроде свайпов-пролистывания в разные стороны. Но и делает невозможными некоторые привычные для десктопа или веба вещи, вроде всплывающей подсказки при наведении мыши. Ведь никакого указателя мыши тут нет.
Я честно думал, что эти сенсорные штучки не привносят ничего нового. Но потом я стал наблюдать, как моя доча, совершенно не умея читать, обращается с планшетом на Android. Её никто не учил им пользоваться. Но она сама ставит интересные ей игры, играет в них, и смотрит мультики. Да ещё и учит пользоваться планшетом бабушку. Сама. Значит, та самая интуитивная понятность интерфейса всё же достигла уровня, когда с интерфейсом могут справиться четырёхлетние дети.
Mobile UI
Мобильный интерфейс должен быть ещё проще, ещё понятнее, ещё красивее, ещё удобнее чем десктопный или веб. Смартфоны теперь в каждом кармане. Потенциальная аудитория ещё больше, чем у веба. И если вы сможете дать пользователю возможность сделать что-то на два тыка быстрее, чем все конкуренты, вы сможете выиграть. Если, конечно, это будет красиво :) И если вы сможете сделать красивее и удобнее, но абсолютно то же самое, что у всех конкурентов, вы тоже сможете выиграть.
Удобство — это, не в последнюю очередь, отзывчивость интерфейса. А отзывчивый интерфейс можно построить только экономя на ресурсах. Хоть ядер и памяти в современных смартфонах побольше, чем на иных ноутбуках, они вовсе не все всегда задействованы. У нас ведь ещё и очень маленькая батарейка, чей заряд нужно беречь. Поэтому веб приложения, хоть и очень очень стараются стать ещё и мобильными, через те же WebView, всё ещё не так продвинулись в мобилках, как уже отвоевали себе пространство на десктопах. Может, это и хорошо. Может, это и плохо.
Я уже много лет жду, когда, наконец, появится технология, которая позволит делать одинаково удобные, отзывчивые и нативные приложения под десктоп, веб и мобилки. Но пока подобного решения не предвидится. Всё же размер экрана имеет значение, и интерфейс мобилки нужно строить по совсем другим принципам, отличным от десктопного.
UI toolkits
Кстати, заметили, происходит «мобилизация» веба. Так как мобильных пользователей больше, сайты стали упрощать интерфейс, укрупнять элементы управления, внедрять адаптивную вёрстку. Чтобы на экране телефона смотрелось прилично. А на десктопе как-нибудь перебьёмся.
Что дальше? На подходе у нас виртуальная реальность (она же VR), где пользователь полностью погружается в виртуальный мир. (Привет, «Газонокосильщик».) И так же на подходе дополненная реальность (она же AR), где пользователь видит виртуальные предметы или метки поверх своего обычного восприятия реальности. По мне, так существенная разница лишь в том, какая часть реальной реальности замещается виртуальной.
Для этих реальностей нужны специальные устройства вывода: шлемы, очки и всё такое. Нужны и специальные устройства ввода, нужен указатель в трёхмерном пространстве: перчатки или что-то подобное. И нужны какие-то новые способы организации интерфейса пользователя. Какие именно, пока, похоже, не очень понятно.
Microsoft HoloLens
А вот пример Google Glass показал, что интерфейс может быть голосовым. А успех(?) таких устройств, как Amazon Echo и Google Home показывает, что сам по себе голосовой интерфейс, без других способов взаимодействия, тоже имеет ценность.
Amazon Echo
Каким должен быть голосовой интерфейс? Кто знает? Очевидно только, что никто не сможет надиктовать, скажем, программу на C. Так что ввод текста и чтение текста никуда не денутся.

2017-02-05

Об OAuth

Веб — странное место. Нормального входа по логину-паролю всем скоро стало не хватать. Сервисов слишком много, нормальный человек столько паролей не придумает. Поэтому появился OpenID.
OpenID — это распределённая система аутентификации в вебе. Пользователю не обязательно заводить отдельный идентификатор (и пароль) для каждого ресурса, достаточно зарегистрироваться на одном (любом) провайдере OpenID. (И эти провайдеры вполне себе функционируют и ныне, хотя потихонечку отмирают.) А затем использовать этот идентификатор OpenID (который представляет собой просто URL) для аутентификации на любом ресурсе, который эту самую аутентификацию через OpenID поддерживает.
Но мы же движемся к семантическому вебу, к интернету для роботов, сами того не осознавая. И логиниться под одним паролем всюду оказалось мало. Оказалось, нужно, чтобы один веб сервис (т.е. робот) мог обращаться к другому веб сервису (т.е. его API) от имени пользователя. Ну, чтобы какой-нибудь бот мог читать ваши твиты, не давать же ему пароль от Твиттера? Для решения этой задачи придумали OAuth.
OAuth называют протоколом авторизации. Это не проверка идентичности пользователя, т.е. аутентификация. Это предоставление доступа (от имени пользователя), т.е. авторизация.
На самом деле OAuth — целых две штуки. Версия 1.0 оказалась настолько сложной, что буквально единицы сервисов (например, Twitter) его успели внедрить до появления OAuth 2.0. Версию 2.0 специально упростили. Но в результате не специфицировали многие моменты поведения. Пытались это дело устаканить, махнули на всё рукой, и «протокол» переименовали во «фреймворк».
OAuth 2.0 logo
Более менее формальное описание OAuth 2.0 изложено в RFC 6749 (2012 год, за авторством Майкрософта). Это документик о двенадцати главах, трёх приложениях и семидесяти шести страницах. Но его прочтение (по слухам) не поможет вам создать своего OAuth провайдера. А передо мной возникла такая задача. Но одни правильные ребята написали правильную книжку, где всего на сорока пяти веб страничках изложены все основы OAuth 2.0, с объяснениями и примерами кода. Для создания OAuth клиента для любого OAuth провайдера достаточно будет прочитать первые пять страниц.
Итак. У нас есть юзер, т.е. человек, который знает пароль и владеет некоторыми ресурсами на некотором сервисе. У нас есть этот сервис, где есть твиты, картинки, документы и прочие ресурсы, принадлежащие этому человеку. У нас есть другой сервис, клиент OAuth, который хочет получить доступ к этим самым ресурсам этого человека. И у нас есть сервер авторизации OAuth, который может дать права клиенту на ресурсы. Сервер авторизации и сервер ресурсов, понятное дело, должны как-то взаимодействовать (как именно, OAuth не волнует), поэтому часто это вообще один сервер.
OAuth 2.0 roles
Допустим, мы создали новую, милую и хорошую веб службу. И этой службе нужно получить доступ, например, к профилю пользователя на Google. Собственно, получение доступа к профилю пользователя на каком-то солидном и популярном ресурсе или социальной сети, чтобы узнать его имя, и, допустим, email, вполне достаточно для аутентификации пользователя на вашем маленьком сервисе. Это и называется «войти через Google/Facebook/VKontakte/etc».
Для начала нам нужно нашу службу зарегистрировать на сервере авторизации. Везде это делается по-разному. Чаще всего это всякие девелоперские настройки вашего профиля, список авторизованных OAuth приложений, и тому подобное. Вы должны указать название и описание вашего сервиса, вероятно, некоторую иконку, а также очень важный параметр: Redirect URI. Это URI/URL на вашем сервисе, куда, в виде колбэка, будет приходить важная информация от сервера авторизации. Таких URI, как правило, можно указать несколько.
Взамен вам, для вашего сервиса, выдадут Client ID и Client Secret. Это просто две длинные строки, которые нужно будет вписать куда-то в настройки вашего приложения. Client Secret — это аналог пароля, поэтому хранить его нужно соответствующе, по возможности шифруя.
От сервера авторизации вам нужно знать ещё два URL, два метода его API: URL авторизации и URL получения токена. Они обычно заканчиваются на что-нибудь вроде oauth/authorize и oauth/token.
Итак, где-то у вас на сайте есть кнопочки вроде «Log in with Google» или «Connect to Google Drive». Когда пользователь их нажимает, начинается процедура авторизации. Ваш сервис перенаправляет браузер пользователя на oauth/authorize сервера авторизации. При этом в URL добавляются параметры.
  • client_id — тот самый идентификатор клиента, что вам выдали при регистрации вашего сервиса.
  • response_type — ожидаемый тип ответа от сервера авторизации, для данного случая должен быть «code». Хотя некоторые серверы авторизации не требуют этого параметра, ибо поддерживают только один вариант авторизации.
  • redirect_uri — один из тех адресов возврата, что вы указывали при регистрации.
  • scope — описание того, какие права вы хотите получить для доступа к ресурсам. Только читать твиты или ещё их и постить? Формат этого параметра определяется исключительно сервером авторизации (и сервером ресурсов). Обычно это какой-то набор строк (или URL), разделённых пробелами, по отдельной специальной строке для каждого разрешения. Гранулярность разрешений тоже зависит от сервера ресурсов. Например, у Google получить просто имя пользователя — это «profile», а узнать его емейлы — это дополнительно «email».
  • state — некоторое «состояние» вашего сервиса, эта строка просто вернётся вам без изменения в конце, можно использовать, чтобы отличить один ответ от сервера авторизации от другого. Точнее даже нужно использовать, для защиты от CSRF атак.
Таким образом, в браузере пользователя открывается некоторая страница сервера авторизации. Что там происходит, определяется исключительно этим самым сервером. Если пользователь не залогинен на этом сервере, его попросят ввести логин и пароль. Если залогинен, сразу будет показана следующая страница. На этой следующей странице пользователь должен явно разрешить доступ вашему приложению. Тут будет отображаться то самое имя, описание и иконка вашего приложения, что вы указали при регистрации. Так что давайте внятное описание, чтобы пользователь не испугался.
Кроме того, будут явно показаны те разрешения (scope), что запросило ваше приложение. На особо продвинутых серверах авторизации пользователь даже может снять некоторые галочки, и в результате разрешить несколько меньше, чем ваше приложение запрашивает.
Пользователь подумает-подумает, да и нажмёт на кнопку «Allow». Это — успех. Сервер авторизации, запомнив решение пользователя, редиректнет браузер на тот самый redirect URI. Здесь придут два параметра.
  • code — временный код для получения токена доступа. Некая произвольная строка. Срок действия этого кода — не больше нескольких минут.
  • state — тот state, который вы посылали ранее, без изменений.
Ну вы же запрашивали «response_type=code», и получили «code».
Если что-то пошло не так, то либо ошибка будет показана где-то на страницах сервера авторизации, и никакого редиректа не будет. Либо в вашем редиректе появятся параметры error, error_description или даже error_uri, показывающие код, описание или, соответственно, адрес страницы с описанием ошибки.
Мы получили code. Ваш сервер не должен этот код нигде хранить, а должен немедленно обменять его на токен. Для этого нужно сделать запрос на второй URL сервера авторизации. Нужно сделать POST на oauth/token. Сделать не из браузера, а из бэкенда вашего приложения. И передать другие параметры в теле запроса, в виде x-www-form-urlencoded данных.
  • grant_type — способ получения токена, в данном случае по коду, поэтому значение этого параметра должно быть «authorization_code». Некоторые серверы авторизации не используют этот параметр, потому что поддерживают только один вариант авторизации.
  • code — тот самый код, который вы получили от сервера авторизации шагом ранее.
  • redirect_uri — снова redirect uri, чтобы лишний раз подтвердить, что вы — это вы. Нужен ли он, зависит от сервера авторизации.
Клиент, т.е. ваш сервер, должен аутентифицировать себя для получения токена. Чаще всего для этого к запросу добавляются ещё два параметра.
  • client_id — снова ваш идентификатор клиента.
  • client_secret — тот самый секрет, который вы получили при регистрации, наконец-то он пригодился.
Или же идентификатор клиента и секрет выступают в роли имени пользователя и пароля и передаются в HTTP заголовке «Authorization», согласно Basic Auth. Или же достаточно обычного GET запроса, а все параметры передаются в виде обычного query. Тут все нюансы снова определяются сервером авторизации.
В ответ за запрос токена сервер авторизации возвращает нам (наконец-то) обыкновенный JSON. Этот JSON не содержит вложенных объектов, а только свойства в объекте верхнего уровня. Эти свойства нам и нужны.
  • access_token — тот самый токен доступа, ради которого всё это затевалось.
  • token_type — некая подсказка, как этим токеном пользоваться. Часто просто строка «bearer».
  • expires_in — сервер авторизации может указать время жизни выданного токена.
  • refresh_token — сервер авторизации может выдать дополнительный токен, который может использоваться для обновления основного токена без прохождения всей этой длинной процедуры авторизации. Это имеет смысл из соображений безопасности, чтобы основной токен менялся почаще, но при этом доступ был подольше.
  • scope — если пользователь снимал галочки и урезал доступ вашему приложению, тут может вернуться актуальный scope, который отличается от того, что вы запрашивали.
  • state — state может вернуться и здесь.
Если что-то пошло не так, то в JSONе ответа снова будут поля error, error_description или даже error_uri.
Ну вот почти и всё. Теперь у вас есть access_token. Он даёт право вашему приложению делать какие-то действия, ограниченные scope, от имени данного авторизованного пользователя на сервере ресурсов. Нужно только в каждом запросе на API сервера включать этот токен. В простейшем случае токен добавляется к запросу как параметр с именем «access_token» или «token». Или же нужно посылать заголовок «Authorization» типа «Bearer».
Authorization: Bearer <access_token_here>
Тут нюансы снова зависят от сервера авторизации и конкретного сервера ресурсов. Потому OAuth и назвали «фреймворком», на «протокол» не тянет, ибо слишком многие детали отданы на откуп конкретным реализациям. А от этих деталей очень сильно может зависеть секурность протокола вообще, именно поэтому OAuth 2.0 справедливо критикуют за дырявость.
Даже в рамках одного OAuth параметры авторизации могут передаваться в query части URL, в теле запроса, включая x-www-form-urlencoded и JSON (хорошо, что без XML обошлись), или в заголовках. Но, поверьте мне, OAuth всё же не выиграет приз в номинации «Наибольшее разнообразие способов передачи параметров в HTTP в рамках одной спецификации».
OAuth with auth code workflow
В рассмотренном выше наш сервер должен держать где-нибудь в конфигах два параметра: Client ID и Client Secret. Иногда это считается небезопасным, когда код не является доверенным, потому что пользователь (потенциально) имеет к нему (коду) полный доступ и может (потенциально) модифицировать его по своему желанию. Это касается приложений, выполняющихся в браузере (т.е. на JavaScript), и мобильных приложений (т.е. под iOS и Android, например).
Для такого случая Client Secret не выдаётся (не нужен), а получение токена происходит посредством так называемого implicit grant.
В первом запросе, на oauth/authorize, в параметре response_type указывается другое значение: «token». Т.е. мы говорим серверу авторизации, что не хотим никаких промежуточных кодов, а хотим сразу токен.
И сервер авторизации редиректит назад с двумя параметрами: token и state. Т.е. мы сразу получаем наш вожделенный токен. Но вот передаётся этот токен не в query, а во fragment.
https://my.cool.app/oauth/callback#token=Yzk5ZDczMzRlNDEwY&state=TY2OTZhZGFk
Фрагмент не передаётся на сервер, но доступен из JavaScript. А мы вроде как и не хотели его никому, кроме как коду на JavaScript, давать.
С мобильными приложениями всё ещё интереснее. Страницы сервера авторизации, с логином/паролем и кнопкой «Allow» отображаются в системном браузере или WebView. Куда происходит редирект? Вообще-то, куда угодно.
Сервера у нас нет, поэтому редиректить надо на приложение. В Android приложение можно навесить на открытие любого URL. В iOS нужно регистрировать для приложения свою схему URI, и редирект получается на нечто вроде «mycoolapp://oauth/callback#token=xxx&state=yyy».
В принципе, если мобильное приложение контролирует WebView, можно вообще никуда не редиректить, а просто отловить ответ 302 Found от сервера авторизации и взять заголовок «Location», т.е. адрес, куда должен произойти редирект.
В любом случае мобильное приложение получает доступ к URI редиректа, и получает оттуда токен. Ну а потом использует этот токен как обычно, добавляя в запросы к API сервера ресурсов.
Получается, что Redirect URI — это действительно URI, а не просто URL. Сервер авторизации особо к его содержимому не придирается. Главное, чтобы этот URI, полученный от клиента, в точности совпадал с URI, указанным клиентом при регистрации.
Поэтому, кстати, вполне можно тестировать OAuth локально, указав в Redirect URI что-нибудь вроде «http://localhost:12345/test/callback».
OAuth implicit grant workflow
Если вы успешно переварили всё то, что тут было написано, вы сможете разобраться с этим скриптом. И поймёте, зачем там запускать браузер. Это вполне реальный пример мелкой автоматизации манипуляций через Slack API с использованием OAuth 2.0. Удачи.
Ещё раз, хотите сделать свой OAuth 2.0 руками — сначала прочитайте OAuth.com.