Как я могу разработать безопасный API / аутентификацию для мобильных приложений для доступа к сервису?

Question

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

Из того, с чем я столкнулся до сих пор в отношении других API, например GoogleMaps, это то, что сторонний разработчик регистрируется на моем сайте, он получает ключ API (некоторый случайный UUID) и должен использовать его для аутентификации своих запросов на моем сайте. Пока все хорошо ...

Существует ли механизм защиты конечного пользователя мобильного приложения от вредоносных приложений? Например. сторонний разработчик может создать приложение и получить все имена пользователей и пароли от конечного пользователя, чтобы он мог делать плохие вещи с помощью useraccount. (Например, я мог бы создать приложение для твиттера, захватить все имена пользователей и пароли, а затем удалить все их твиты, опубликовать новые ...) Есть ли возможность предотвратить это? AFAIK, вы можете использовать oauth в Интернете, чтобы окно входа в систему my отображалось на другом сайте и запрашивало у них имя пользователя / пароль, чтобы оно не отображалось на стороннем сайте. Можно ли реализовать безопасную аутентификацию для приложений смартфона? Как бы вы это сделали?

Answer 1

Для Android и iPhone вы можете использовать OAuth без проблем, и пока я думаю, что это лучший способ сделать это.

Процесс для этих двух типов смартфонов такой же, как и в веб-приложениях, потому что обе ОС дают вам возможность запустить веб-браузер из вашего приложения и перенаправить пользователя к веб-провайдеру, чтобы он мог авторизовать ваш запрос (токен), и затем браузер может вернуть вашего пользователя в приложение через надлежащий URI обратного вызова. Я не реализовал oauth для мобильных телефонов, но слышал от друга, что это возможно, и что мобильный браузер может перенаправить пользователя обратно в ваше приложение с помощью специального URI, например scheme://app/parameters.

Вот что-то для этого с Android: ссылка

Существует два варианта использования: 2-х и 3-х

2-legged - это когда вы хотите защитить свой API, чтобы его можно было вызывать только из аутентифицированных пользовательских приложений. Это популярная схема, существующая с давних пор AFAIK - потребитель подписывает каждый запрос с помощью общего ключа потребителя, а провайдер (ваш API) также подписывает запрос, чтобы проверить, совпадает ли подпись. Таким образом, вы можете определить, подходит ли использование API для этого потребителя.

Трехсторонний oauth включает конечного пользователя стороннего приложения. Это очень удобно, если вы хотите снова защитить свой API, как в двухстороннем, потому что запросы все еще подписаны, но и ваш API может быть защищен с разрешения конечного пользователя. Поставщик API выдает токен и передает его клиентскому приложению (стороннему приложению). Затем это приложение сохраняет токен локально и перенаправляет пользователя к провайдеру для авторизации токена. Когда пользователь авторизует его, провайдер отправляет его обратно в приложение потребителя, а затем потребитель может отправлять аутентифицированные (подписанные) и авторизованные (пользователем - третья сторона) запросы к вашему API.

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

Это очень хороший сайт для чтения о oauth: http://hueniverse.com/oauth/

--- ДОБАВИТЬ ВКЛ ---

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

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

Answer 2

На ваш второй вопрос:

Преимущества oauth:

1. У пользователя может запрашиваться разрешение при доступе к чувствительному API-интерфейсу третьей стороной;

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

Например, если вы являетесь gmail-провайдером API и предоставляете метод веб-сервиса login(user, pass) сторонним разработчикам приложений, они могут создать экран входа в систему и войти в систему.пользователи.Однако в этом процессе их стороннее приложение напрямую получает учетные данные пользователя перед отправкой их в gmail.Я бы никогда не использовал такое приложение.Проблема заключается в том, что большинство людей не знакомы (особенно не технические специалисты) с последствиями использования таких приложений, и люди, создающие приложения, все еще используют этот старый и небезопасный способ работы.Однако по мере того, как все больше людей будут заниматься реализацией какого-либо протокола безопасности, такого как oauth (или аналогичного), люди будут знакомы с этими потоками и станут более подозрительными к таким навязчивым сторонним приложениям.

Я говорю навязчиво, потому что представьтена мгновение следующий сценарий:

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

И этот API-интерфейс провайдера защищен открытым способом входа в систему веб-службы (пользователь, пароль).После того, как стороннее приложение использует этот метод с учетными данными пользователя (которые оно уже использовало), оно получает доступ к методу charge(user, amount).Затем он может вызвать этот метод API с любыми параметрами и запросить у пользователя one hundred thousand million pessos: D

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

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