Авторизация может выглядеть следующим образом - сервер выдает токен (некое число, секретное, временное, чье время действия может продляться при его использовании), основанный на каких то идентификационных данных клиента (идентификатор компьютера или установки приложения, сетевой ip адрес и т.п., этот вопрос не простой и ответ на него определит серьезность проверки на действия злоумышленника, который попытается украсть этот токен).
Т.е. приложение смотрит, есть ли токен в памяти,
* если нет - открывает форму авторизации, и в месте с данными из нее (точнее обработанные каким-нибудь алгоритмом криптонадежного хеширования) отправляет на сервер идентификатор клиента, сервер проверяет, можно ли давать доступ, прекращает работу выданных ранее этому же клиенту токенов, и выдает новый.
* если токен есть - приложение делает запрос с этим токеном и своими идентификаторами (так же хешированными) на сервер, а он в свою очередь проверяет, не закончилось ли время действия токена и выдает либо да либо нет.
Процесс авторизации можно воспринимать как выдачу ключа активации (например при покупке своей копии программы).
Нужно понимать что эту проверку можно обойти, убрав этот запрос из кода в принципе. Более надежным является перенос части или всего функционала приложения на серверную сторону, в этом случаее взломать так просто не получится но и работа может быть не такой комфортной из-за лагов, да и нагрузка на сервер станет выше.