Если по простому,а судя по вопросу это именно так, то как то так.
Для начала вникаем что такое авторизация и регистрация и из чего состоит. Получится что есть клиент и сервер.
Клиент для регистрации должен сказать желаемый логин и пароль. Для авторизации можно чуть усложнить и работать по 2м схемам, Первый когда клиент скажет серверу логин и пароль. Во втором логин и токен.
*Токен тут получается после авторизации, его генерирует сервер и сообщает клиенту. Используется для минимальной защиты потому как на клиенте можно не хранить пароль а хранить только логин и токен.
Сервер в свою очередь ждет от клиентов логин и пароль, после получения которых проверяет в своем хранилище(бд например) и отвечает клиенту сообщением состояния(ок, логин занят,ошибка, пароль простой и т.д.). Дальше он ждет от этого клиента авторизацию по одному из двух способов которая может быть по логину и паролю, тут сервер ответит также сообщением(сгенерирует токен, ошибка пароль\логин не верный). 2й вариант что ожидается логин и токен , ответ будет (ок, ошибка токен не верный).
Общаться клиент и сервер естественно будет по сети а вот как решать уже вам. Это может быть:
1) Голые сокеты, проще для понимания т.к. никаких библиотек уже не будет и собственно весь протокол будет ваш.
2) Использовать какую нибудь rest подобную систему. К примеру тупо взяв сервер с php и сделать нечто похожее(понимаете смысл надеюсь) на register.php и auth.php. Соответсвенно запросы с клиента уже будут идти тупо по http
3) Взять че покруче и на порядок сложнее, к примеру netty. Круче сокетов но сложнее в пару сотен раз хотя сделать придется по сути тоже что и на сокетах.
4) Какой нибудь сетевой движек, к примеру kryonet. Тут конечно уже ближе к играм но почему нет? Придется читать доки и следовать принципам библиотеки, ниразу не узнав что такое сериализации и зачем она нужна.
Для практики потом можно усложнять схему, к примеру чтобы сервер уже не просто смотрел на логин и токен клиента но и еще на его ip чтобы он совпадал. Можно обернуть все это шифрованием, реализовываться будет по разному в зависимости от того каким путем пойдете. Реализовать еще и временный токен этой сессии или же тупо еще одним параметром от клиента типа что за устройство, тогда клиент под одним логином сможет авторизоваться одновременно с нескольких устройств и никто никому мешать не будет.
В более серьезных проектах примерна такая же схема как я описал выше но доработанная в пару тысяч раз толще на любой чих и случай жизни.
Конкретно для javafx я тут вообще в этой теме ничего не вижу да и вообще быть ничего не может т.к. это всеголишь библиотека для отрисовки интерфейса программы с коллекциями предназначенными помочь это сделать еще удобнее. Аналогично ей существуют еще ее предшественники awt и swing которые посложнее но темнеменее работают и легче по ресурсам.
