Аутентификация с помощью учетной записи Google для родного настольного приложения с бэкэндом - PullRequest
Новая
       20

Аутентификация с помощью учетной записи Google для родного настольного приложения с бэкэндом

1 голос
/ 05 апреля 2020

У меня есть приложение, которое имеет как бэкэнд, так и внешний интерфейс (в java). Мне нужна аутентификация пользователя, но я бы предпочел не обрабатывать большую часть ее самостоятельно. Поэтому я подумал, что пользователи могут проходить аутентификацию с помощью своих учетных записей Google.

Внутренняя часть в основном реализована, и она отлично работает из браузера:

  1. Я пытаюсь перейти по URL моего сервера, и браузер перенаправлен на страницу входа в Google.
  2. Я вхожу в систему, и браузер перенаправляется обратно на мой сервер, на этот раз с информацией об аутентификации (какой-то токен?), и я получаю ответ.

Но у меня возникают проблемы с выяснением, как настроить это из настольного приложения. Я хотел бы, чтобы в приложении была кнопка входа в систему, которая при нажатии открывает страницу входа в Google в системном браузере для входа пользователя. Если вход выполнен успешно, клиент рабочего стола может использовать информацию из своей учетной записи Google (например, адрес электронной почты), чтобы идентифицировать себя с моим сервером.

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

Я посмотрел руководство Google по OpenID , и оно указало мне на с использованием OAuth2 для установленных приложений. , это правильное решение для моего варианта использования? Или это для приложений, которые имеют только внешний интерфейс и все данные хранятся в настольном приложении?

1 Ответ

0 голосов
/ 27 апреля 2020

Я не совсем уверен, безопасен ли он и соответствует ли он передовому опыту, но я нашел решение. Я использовал идею loopback redirect uri по-своему.

  1. Я запускаю прослушиватель http в настольном приложении на случайном доступном порту, скажем, это порт 54321.
  2. Я хочу связаться с URL на моем сервере. В этом URL я добавляю петлевой порт в качестве аргумента запроса. Таким образом, URL будет выглядеть примерно так: https://myserver.org:8443/signin?loopback_port=54321
  3. Я запускаю системный браузер с этим URL. Сервер требует аутентификации, поэтому браузер перенаправляется в Google для входа в систему и обеспечивает авторизацию доступа приложения к данным моей учетной записи Google.
  4. После завершения входа в Google браузер перенаправляется обратно на URL-адрес мой сервер, который он впервые пытался достичь. Теперь, когда аутентификация завершена, запрос проходит.
  5. Я обновил конечную точку /signin на своем сервере, чтобы вернуть перенаправления на /signin2 (снова с параметром loopback_port). Перенаправление с /signin установит JSESSIONID для повара ie в браузере, и когда мы получим запрос в /signin2, мы можем прочитать, что JSESSIONID.
  6. Когда мы получим В запросе /signin2 мы используем порт обратной связи и jsessionid для создания URL-адреса перенаправления для прослушивателя http в настольном приложении. Jsessionid будет включен в качестве аргумента запроса. Таким образом, браузер перенаправляется на http://localhost:54321/?JSESSIONID=....
  7. Прослушиватель http в настольном приложении анализирует запрос на получение JSESSIONID от cook ie, и он может использовать его в последующих запросах, отправляемых на сервер. Имея этот код ie, сервер связывает запрос настольного приложения с выполненной ранее аутентификацией.
...