Как только собственный клиент Facebook заблокирован, если вы никогда не отправляете секрет вашего клиента, чтобы получить токен доступа?

Question

При интеграции Facebook Вход в приложение, есть, по существу, 2 (OK, есть больше, чем 2, но на этот вопрос я просто озабочен этими 2) способы, чтобы получить маркер доступа:

1. Имейте FB, чтобы вернуть код в свое приложение, которое вы затем обмениваете на токен доступа на свой сервер, добавив секрет вашего клиента. Клиент делает такой вызов: https://www.facebook.com/dialog/oauth?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code, а затем сервер, обрабатывающий URI перенаправления, передает код и клиентский секрет на FB, чтобы получить токен доступа.
2. Имейте FB, чтобы вернуть токен аутентификации прямо на свое приложение в URL-адрес переадресации: https://www.facebook.com/dialog/oauth?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token. В этом случае токен возвращается непосредственно клиенту в фрагменте URL-адреса.

(Выше информация взяты из https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2)

Таким образом, мой вопрос заключается в том, как это второй метод, в котором FB возвращает маркер непосредственно в безопасности, когда вы никогда не должны были доказать клиенту, кто он говорит, что он ? Есть ли у токенов, возвращаемых во втором случае, меньше разрешений, чем в первом случае? Я знаю в Интернете, по умолчанию клиенты получают короткое замыкание (например, 2-часовой токен), но если вы используете SDK для Android или iOS, вы получаете долгоживущие токены, даже если вы никогда не передаете секрет клиента. Таким образом, связанный с этим вопрос заключается в том, каким образом Android-и iOS-SDK от Facebook действительно будут уверены, что клиентское приложение - это то, о ком он говорит, что это (клиентское приложение всегда может быть разобрано, а кто-то может украсть любую информацию, которую вы отправляете в приложении)?

Принципиально я пытаюсь понять, как потоки oauth, которые отправляют токен непосредственно клиенту, без необходимости защищать секретную информацию на стороне сервера, могут быть безопасными.

Answer 1

Это менее безопасный способ транспортировки токенов доступа клиентам. Спецификация OAuth подтверждает это явно в разделе 10.3 (https://tools.ietf.org/html/rfc6749#section-10.3) и более того в разделе 10.16 (https://tools.ietf.org/html/rfc6749#section-10.16).

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

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

Неявный поток защищен в рамках спецификации OAuth - делегированного контроля доступа, он не может использоваться для аутентификации пользователей.