Использование OAuth для контроля доступа ненадежных сторонних сервисов к нашему API

Question

Мне нужен безопасный доступ к API, который будет использоваться ненадежным сторонним сервисом.Мои текущие расследования привели меня к использованию grant_type=“client_credentials” передачи clientId и секрета клиента, который я настроил для третьей стороны на моем сервере идентификации.Однако этот поток, по-видимому, предназначен только для соединений между компьютерами (MTM), где клиенту доверяют.

Я могу понять, почему: если я использую этот поток с HS256, то я вижу очевидный недостаток безопасности:JWT подписывается с использованием общего симметричного ключа.Это означает, что ничто не мешает сторонним производителям генерировать и подписывать свои собственные токены JWT, используя этот ключ и полностью обходя сервер аутентификации.Однако, если я использую RS256, этот недостаток не существует, так как ненадежная сторона имеет доступ только к открытому ключу, поэтому они не могут создавать свои собственные подписанные JWT.

[EDIT]: Теперь я знаю, что вы не должны проверять токены на клиенте, поскольку в этом нет необходимости, и это означает, что им не нужен ключ, поэтому этот «недостаток» спорный.

Мой главныйвопрос в следующем: Это правильный путь для моего варианта использования, или есть другой поток OAuth, который я должен использовать здесь?Все, что я прочитал, говорит о том, что client_credentials тип предоставления должен использоваться только тогда, когда клиент является владельцем ресурса и ему доверяют, и это не мой сценарий - однако тогда они утверждают, что вы должны использовать Implicit или Authorizationкод, который требует участия пользователя и не подходит для моего варианта использования.

Answer 1

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

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

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

• не злонамеренный и ненадежный (NMU): третья сторона сознательно не сделает ничего «плохого» в доступе к вашему сервису.Большинство потребителей будут здесь.
• злонамеренные и недоверенные (MU): третья сторона может сделать что-то «плохое».Ты не знаешь.И если это произойдет, это полностью их вина, и они виноваты.Не вы.

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

Если вы хотите поднять его еще на один уровень, вы можете использовать этот секрет для выдачи долговременного токена доступа к этомуклиент.При использовании JWT ключ подписи может быть симметричным и храниться для вас - поскольку им не нужно проверять токен на своей стороне.Они просто используют это в каждом запросе.Это имеет проблемы, такие как, если бы вы или они узнали, что этот маркер доступа украден?Кроме того, использование долгоживущего JWT - это вообще плохая идея, поэтому я бы использовал для этого токены не-jwt.

Если вы хотите повысить его уровень (самый безопасный): служба аутентификациисам с секретом, который вы им предоставили.Затем вы могли бы выдать им недолговременный токен доступа и долгоживущий токен обновления.Они будут использовать этот токен доступа для всех обычных вызовов API для аутентификации, а когда он истечет, они получат специальную конечную точку API с токеном обновления, чтобы получить новый токен доступа.Кроме того, вы можете менять токен обновления каждый раз, когда они запускают API обновления - это также позволит вам и им обнаруживать кражу токена!(См. , это ).Если вы решите этот подход, то вам также придется позаботиться о некоторых условиях гонки и проблемах с сетью, как указано в этом блоге .Кроме того, вы также можете изменить ключ подписи JWT, поскольку у вас есть токен обновления, который можно использовать для восстановления!Но это даст вам наиболее безопасное решение для вашей проблемы.

Обратите внимание, что сторонняя служба, скорее всего, относится к типу MU, поэтому вы ничего не можете сделать, чтобы обезопасить свою службу для них - в зависимости от того, что делает ваша служба, их данные и «учетная запись» будутпострадавших ..

Надеюсь, этот ответ поможет вам!Не стесняйтесь, напишите мне на Discord, чтобы побольше рассказать об этом.Меня можно найти на этом сервере с именем пользователя rp # 5569.