Маркер доступа OAuth и обновление токена обновления

Я использую свою собственную систему аутентификации OAuth (с поддержкой refresh_token) для приложения, и у меня есть некоторые вопросы о том, как это сделать:

  1. Идентификация клиента: Клиент зарегистрирован на сервере auth и получает client_id и client_secret. Как его создать? есть какая-то связь между обоими значениями?.
  2. Аутентификация пользователя: клиент отправляет user_credentials (например, имя пользователя + пароль) + client_id и получает refresh_token и (temp?) Access_token. Этот access_token является тем, который я должен использовать в дальнейшем запросе, или я должен использовать accesss_token '= F (refresh_token, access_token, client_secret). Во втором случае, на что состоит функция F?
  3. Обновление токена доступа: клиент отправляет client_id, refresh_token и получает access_token (и необязательный новый refresh_token). Требуется ли access_token одно и то же преобразование (что бы оно ни было), как в пункте 2?

Если я ошибаюсь, когда и как используется client_secret? Полные ответы и конкретные примеры будут "вознаграждены".

+2
источник поделиться
2 ответа
  1. Сервер авторизации/аутентификации генерирует эти значения при создании учетной записи с ними (например, при создании учетной записи разработчика в Facebook или Google). Если вы сами делаете эти части, они должны быть криптографически защищенными псевдослучайными числами или буквами. Помните, что идентификатор клиента обычно общедоступен, поэтому выберите достаточно большой набор альфа-чисел (я использую 30 символов). Секрет секретный, и может быть труднее догадаться, поэтому я выбрал 30 цифр с буквами, цифрами и символами. Они не связаны друг с другом, просто один является публичным, а другой - нет.
  2. Обычный способ работы заключается в том, что браузер переадресовывает сервер auth, передавая идентификатор клиента в URL (и перенаправляя uri), а не НЕ идентификатор пользователя и пароль. Весь смысл OAuth2 заключается в том, что клиентская система никогда не видит имя пользователя и пароль, а только сервер auth. После этого перенаправления сервер auth проверяет идентификатор клиента, проверяет имя пользователя/пароль (например), а затем возвращает URL-адрес перенаправления с временным кодом. Этот временный код передается обратно на сервер Auth, чтобы получить токен доступа. Поскольку этот вызов выполняется как POST с сервера, он также передает секрет клиента, чтобы убедиться, что он действительно является правильной клиентской системой, а не тот, кто украл идентификатор клиента из другого места. На этом этапе сервер auth вернет токен доступа (и дополнительный токен обновления - вам не нужно их использовать, я этого не делаю).
  3. Если клиентская система хочет зарегистрировать пользователя без необходимости вводить свое имя пользователя и пароль все время, он может использовать токен обновления, если он доступен, для возврата на сервер Auth, и если сервер Auth счастлив, что токен обновления остается в силе и любые другие бизнес-правила верны, он может вернуть вам еще один токен доступа непосредственно без участия пользователя.

Я рекомендую прочитать здесь спецификацию OAuth2: OAuth2 Spec RFC6749. Это может занять некоторое время, но если вы удалите бит, который вам не нужен, и уменьшите объем данных, в нем есть много полезных примеров.

+3
источник

FIRSTLY. Идентификатором клиента может быть любая строка, которую вы хотите, но она должна быть уникальной для каждого клиента. Это может быть даже выбор клиента, если вы пожелаете. Секрет клиента должен быть криптографически сильной случайной строкой. Вот как вы могли бы сгенерировать его в С#:

RandomNumberGenerator cryptoRandomDataGenerator = new RNGCryptoServiceProvider();
byte[] buffer = new byte[length];
cryptoRandomDataGenerator.GetBytes(buffer);
string uniq = Convert.ToBase64String(buffer);
return uniq;

SECONDLY. Весь смысл OAuth - позволить внешним приложениям делать что-то от вашего имени, не запрашивая ваши учетные данные. Таким образом, вам необходимо внедрить сервер аутентификации, который частично выполняет регистрацию. Пользователь открывает приложение и получает возможность входа в систему с вашего сайта. Вы пытаетесь использовать токены доступа и обновлять токены, как только пользователь вводит свои учетные данные. Затем приложение может просто использовать маркеры для выполнения действий от имени пользователя. Я написал ответ на вопрос, как работает эффективный сервер/поставщик OAuth2.0? что объясняет, как можно использовать токены доступа.
Помните, что необходимость обновления токенов и срок действия токенов доступа зависит только от того, как вы собираетесь их использовать и какова ваша система безопасности.

LASTLY, токен обновления также может быть закодированной HMAC-строкой/объектом JSON, как я объяснил в ответе на связанный вопрос. У вас могут быть случайные токены обновления и большое бэкэнд-хранилище, чтобы он мог проверять токены во входящих запросах или иметь закодированные строки HMAC для добавления требований/латентности хранения/задержки хранения для дешифрования/шифрования токенов.

Кроме того, убедитесь, что вы проходите через все потоки и, возможно, RFC, как упоминалось Lukos.

0
источник

Посмотрите другие вопросы по меткам или Задайте вопрос