Используйте auth0 для авторизации приложения * NON-web * и получения токена доступа API - PullRequest
0 голосов
/ 03 сентября 2018

(Внимание: впереди, скорее всего, часто задаваемые вопросы, но я, вероятно, упускаю что-то очевидное, поэтому мне нужно, чтобы кто-то озадачил меня, изложив это).

Контекст

У меня есть сервер , который соответствует приложению в моем провайдере oauth (auth0 в моем случае). Это приложение имеет идентификатор клиента / секрет.

Вариант использования веб-страницы (TL; DR: перенаправление работает)

У меня есть веб-сервер, который может обслуживать веб-страницу, которая перенаправляет на страницу входа в систему auth0 и проверяет, является ли пользователь тем, кем он себя считает.

Таким образом, Алиса может открыть веб-страницу, войти в систему с помощью auth0 и использовать мое приложение.

API usecase (TL; DR: секрет для клиента)

Теперь этот сервер также имеет набор API, и для этих API требуется заголовок Authorization: Bearer xxxx с токеном JWT.

Этот API также соответствует ресурсу "API" в Auth0.

Теперь я могу легко создать другое приложение в auth0, которое имеет другой набор идентификатора клиента / секрета и которое может использовать "oauth / token" для получения access_token .

 POST https://xxxx.auth0.com/oauth/token
        Content-Type: application/json
        {
          "client_id": "[client_id]",
          "client_secret": "[client_secret]",
          "audience": "https://yyyy/api",
          "grant_type": "client_credentials"
 }

И этот секрет является секретом, потому что я (надежно) отдаю его Бобу, и Боб помещает его на свой сервер, и он остается на сервере Бобса, а сервер Боба может выполнять вызов API.

Кейс для настольного приложения (TL; DR: это секрет, если я делюсь им только с одним человеком за раз?)

Но теперь я хочу, чтобы Алиса могла запускать настольное приложение, которое выполняет вызов API.

И я хочу, чтобы сервер API мог знать, что это Алиса, поэтому мне действительно нужен JWT с заявкой пользователя.

Кажется, что эта ситуация должна охватываться потоком Код авторизации .

А я понимаю, этот поток предполагает, что:

  • мое настольное приложение открывает браузер
  • этот браузер переходит на xxxx.auth0/authorize, с client_id в качестве параметра
  • браузер перенаправляет на мое настольное приложение, которое предположительно прослушивает localhost, чтобы получить code
  • мое приложение затем отправляет запрос POST на xxx.auth0/oauth/token с кодом _ и с client_secret_

Существует множество библиотек, которые могут помочь в этом.

Я просто не могу понять, как мое настольное приложение сможет отправлять client_secret на auth0, и все еще держать его, ну, в общем, "в секрете".

Это неправильный поток?

Существуют другие потоки Oauth2 , но я понимаю, что я не могу использовать другие:

  • "Является ли клиент владельцем ресурса" => Нет
  • «Является ли клиент веб-приложением на сервере» => Нет
  • "Доверяет ли клиент учетные данные пользователя" => Я думаю "НЕТ", но я здесь не прав?
  • «Является ли клиент SPA» => Нет, в том смысле, что он не работает в браузере
  • "Предоставление кода авторизации (PKCE") "=> То, что могло бы работать, но я не видел ни одной библиотеки C ++, которая реализует часть" PKCE "- посылку вызова вместо секрета. быть дорогой, чтобы идти?
...