В чем преимущество использования Auth0 с gRPC?

Я прочитал этот пример:https://auth0.com/blog/securing-grpc-microservices-dotnet-core/.

В этом примере объясняется, как реализовать авторизацию в gRPC сервисе.

В нем говорится, что клиент запрашивает токен, который позволяет клиенту вызвать сервис. Для этого необходимо включить в json-файл публичные и приватные данные, с помощью которых можно получить этот токен.

{
  "Auth0": {
    "Domain": "YOUR_AUTH0_DOMAIN",
    "Audience": "YOUR_UNIQUE_IDENTIFIER",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientSecret": "YOUR_CLIENT_SECRET"
  }
}

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

Для этого, я полагаю, это то же самое, что если я создаю самоподписанный сертификат и добавляю CA.crt, client.crt и client.key в приложение.

Возможно, я неправильно понял какую-то часть, но если это верно, то вся информация, необходимая для получения токена, находится в клиенте и процесс происходит следующим образом:

• Клиент получает токен от Auth0.
• Клиент использует токен для вызова сервера.
• Служба аутентифицирует вызов, поскольку токен действителен.

Где в этом случае безопасность?

Спасибо.

Где в этом случае безопасность?

В том, как вы:

1. Держите appsettings.json в секрете и недоступны
2. Держите appsettings.json подальше от SCM (хранилища исходного кода)
3. Внедрять этот файл или значения свойств в среду выполнения безопасным способом (зашифрованным, не отслеживаемым и т.д.)
4. Шифруйте всю интеграцию и расшифровывайте только тогда, когда значение необходимо¹

Цитата Auth0 очень четко говорит об этом

Вы собираетесь хранить учетные данные клиента gRPC в файле appsettings.json. Имейте в виду, что вы можете сделать это только потому, что сценарий вашей системы - это сценарий "машина-машина".

Помните: никогда не храните учетные данные в общедоступном клиенте.

Безопасность часто является общей моделью. Поставщики услуг гарантируют безопасность в своих системах и, зачастую, гарантируют безопасность при передаче данных, которые они хранят для вас. Но как только данные попадают в вашу систему, вы несете полную ответственность за их безопасность.

Если бы вы реализовали пример Auath0 в веб-приложении, вы бы делали то, о чем вас просят не делать.

Тогда решением будет размещение интеграции с Auth0 на стороне вашего сервера, где вы должны обеспечить (можете ли вы?) свои собственные политики безопасности.

Заметьте, что даже пример Auth0 "машина к машине" довольно наивен с точки зрения безопасности. Но это разумно, поскольку статья посвящена только интеграции Auth0, а не тому, как сделать всю вашу систему безопасной.

^{1: Or keep it in memory in the right type (I always have to recall the Character[] vs string or that sort of practice to avoid others cathing values from dumps or profilers)}