Идентификатор клиента OAuth 2.0 для мобильного нативного приложения и чистого JS-клиента

#oauth-2.0 #oauth #identityserver4 #identityserver3

#oauth-2.0 #oauth #identityserver4 #identityserver3

Вопрос:

Я повторно загружал документы OAuth и понимаю, что https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce это лучше, чем поток кода авторизации, потому что это дает меньше возможностей для получения клиентского кода и обмена его на access_token

Также я видел, что в Интернете были случаи, когда клиентские секреты менялись местами с большими мобильными приложениями, такими как facebook или Twitter

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

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

Итак, вопрос, есть ли какие-либо способы правильно реализовать идентификатор клиента для мобильных приложений и чистых клиентов JS (браузера)?

ОБНОВЛЕНИЕ есть 2 отличных варианта: 1 — использовать URL-адреса перенаправления 2 — настроить CORS

1 однако я думаю, что это не поможет, если я попытаюсь имитировать поведение bahaviour с помощью внутреннего кода. Например, мне действительно не нужно иметь доступ к веб-сайту, чтобы увидеть, что в какой-то момент он перенаправит заголовок, и я просто получу сообщение и получу этот код авторизации. 2 на самом деле мне не нужно иметь доступ к веб-сайту, чтобы увидеть, что в какой-то момент он перенаправит заголовок, и я просто получу сообщение и получу этот код авторизации.то же самое для CORS в случае, если для моего зеркального сайта я буду получать токен из серверной части, сервер не будет определять, что клиент не является оригиналом и имеет права на работу с этим клиентом

Ответ №1:

Итак, вопрос, есть ли какие-либо способы правильной реализации идентификации клиента для мобильных приложений и чистых клиентов JS (браузера)?

Согласно спецификации, аутентификация клиента обязательна для потока кода авторизации. redirection URI это предлагаемое решение, помогающее при аутентификации клиента.
Вот параметры IDS4, которые помогут аутентифицировать клиента:

  1. Использование RedirectUris конфигурации клиента для указания разрешенных URI для возврата токенов или кодов авторизации. Ссылка
  2. использование CORS. Политика того же источника браузера блокирует чтение ресурса из другого источника. Мы можем добавить нашего клиента в список разрешенных вызовов с перекрестным источником.

Пример кода:

 new Client
{
    ClientId = "js",
    ClientName = "JavaScript Client",
    AllowedGrantTypes = GrantTypes.Code,
    RequireClientSecret = false,
    RedirectUris = { "https://localhost:5003/callback.html" },
    PostLogoutRedirectUris = { "https://localhost:5003/index.html" },
    AllowedCorsOrigins = { "https://localhost:5003" },
    AllowedScopes =
    {
        IdentityServerConstants.StandardScopes.OpenId,
        IdentityServerConstants.StandardScopes.Profile
    }
}

  

Комментарии:

1. Спасибо за ваш ответ. AllowedCorsOrigins = { » localhost:5003 » } — это именно то, что я искал.

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

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

4. То, что вы говорите, называется атакой подстановки кода . PKCE — это решение для его смягчения. Простым словом, наличие аутентификации клиента (идентификатор клиента URL перенаправления CORS) PKCE значительно усложняет взлом. Поскольку задействовано несколько проверок и случайно сгенерированных значений. Посредник должен сидеть на компьютере пользователя и выполнять фишинг, чтобы добиться успеха. Подробнее docs.identityserver.io/en/latest/topics /…

5. PKCE является ли он официальной рекомендацией для нативных приложений (ссылка: tools.ietf.org/html/rfc8252#section-6 )