Может ли Oauth безопасно использоваться на стороне клиента для внутреннего сервиса? - PullRequest
0 голосов
/ 02 июня 2019

У меня есть веб-приложение (C # / Javascript), где я хочу вызвать внутреннюю службу, которой я владею.Я хочу защитить эту службу, чтобы ее могли вызывать только мои приложения.Похоже, если я использую Oauth на стороне клиента, секрет раскрыт?Все документы, которые я читаю об Oauth, дают решения, когда пользователь приложения владеет ресурсом, а не когда само приложение им владеет.Я смотрел на то, как работает Google API, и библиотеки JavaScript, кажется, предоставляют ключ на стороне клиента, не так ли?

Ответы [ 2 ]

1 голос
/ 04 июня 2019

Да, вы можете сделать это с помощью OAuth, но то, как вы это сделаете, зависит от того, как организованы данные, к которым осуществляется доступ через вашу серверную службу.Если данные на самом деле относятся к конкретному пользователю, то ваш пользователь действительно является владельцем ресурса.В этом случае вы будете использовать типичный код авторизации.С этим типом предоставления вы регистрируете клиента на сервере аутентификации OAuth и получаете client_id и client_secret.Client_id действительно отображается в браузере, но client_secret находится на сервере вашего веб-приложения и никогда не отображается.Он отправляется только по запросам обратного канала (без браузера) на ваш сервер аутентификации.Главное здесь - то, что только ваше собственное клиентское веб-приложение будет зарегистрировано и получит client_id / client_secret.Вам просто не нужно предоставлять конечные точки публичной регистрации, чтобы другие клиенты не могли зарегистрироваться.С этим типом гранта, чтобы ваше веб-приложение получило авторизацию для доступа к данным пользователя в фоновой службе, пользователю необходимо будет подтвердить авторизацию в браузере как часть процесса.

Вкл.с другой стороны, если данные, к которым вы обращаетесь в своей серверной службе, не зависят от пользователя, вы можете использовать грант OAuth Client Credentials.С этим типом гранта вы регистрируете клиента, как и раньше, и получаете client_id и client_secret.Секрет надежно хранится на сервере веб-приложений и передается только в запросах обратного канала.Вы бы не позволяли другим клиентам регистрироваться.Затем ваше веб-приложение может получить авторизацию для вашей серверной службы, даже не требуя авторизации пользователя в браузере.

0 голосов
/ 03 июня 2019

Боюсь, что нет способа ограничить вызов вашего API только кодом ваших приложений. Приложения браузера с открытыми кодами не могут хранить какой-либо секрет (например, сертификат), который бы их идентифицировал, потому что любой может извлечь его из кода. Настольные и мобильные приложения, скомпилированные с помощью байт-кода, не так легко прочитать, но, приложив некоторые усилия, злоумышленник сможет найти секретные данные. Это также причина, почему эти приложения (так называемые публичные клиенты) не хранят client_secret, если они действуют как клиенты OAuth2. Вместо этого они используют одноразовый секрет - PKCE .

Что вы можете сделать, это проверить аудиторию (для какого идентификатора клиента был выдан токен) токена доступа, отправленного из внешнего интерфейса в ваш бэкэнд. Вы можете получить эту информацию либо из конечной точки самоанализа (aud атрибут), либо из атрибутов JWT , если токен имеет тип JWT.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...