#google-cloud-platform #google-bigquery #google-python-api
# #google-облачная платформа #google-bigquery #google-python-api
Вопрос:
У меня есть приложение, интегрированное с сервисами Google (точнее, с API Google Bigquery).)
Я аутентифицирую пользователя на стороне клиента без областей автономного доступа (следовательно, без токенов обновления) и выполняю большинство операций на стороне клиента. Но есть некоторые операции, которые я хочу выполнить на стороне сервера (все еще от имени аутентифицированного пользователя).
В настоящее время я передаю токены доступа на сторону сервера (через https), инициализирую библиотеки Google на стороне сервера с помощью этого токена и выполняю там операции.
Документация, которую я нашел в Google по этому поводу, либо использует аутентификацию на стороне сервера, с токенами обновления, либо полностью на стороне клиента. Не удалось найти документацию, предлагающую рекомендации для этого смешанного случая.
Короче говоря, то, что я хочу сделать, это использовать недолговечные токены доступа, полученные на стороне клиента на серверной части.
Существуют ли какие-либо риски для безопасности при таком подходе? И независимо от этого, является ли это предлагаемым способом сделать то, что я хочу?
Комментарии:
1. Привет @Ozgur, я чувствую, что это немного не по теме и очень общий секретный вопрос, не обязательно связанный с BigQuery. Говоря это в качестве подсказки, я всегда предлагаю / предпочитаю хранить токен на стороне сервера и использовать логику на стороне сервера, поскольку это намного безопаснее по многим причинам.
2. @TamirKlein большое спасибо за ваш отзыв. Обычно я бы также использовал привязку токена к серверной части, но для этого потребовалось бы получить разрешение на автономный доступ от пользователей, чего я не хочу. Вот почему я пытаюсь использовать токен, полученный на стороне клиента.
Ответ №1:
Независимо от реализации BigQuery OAuth2, на рынке рекомендуется хранить ТОЛЬКО краткосрочный токен безопасности на стороне клиента. Даже это может быть проблемой в зависимости от вашей технологии и структуры безопасности клиента.
Два важных момента из официальной платформы авторизации OAuth 2.0: использование токена на предъявителя
Хранилище токенов
Не храните токены на предъявителя в файлах cookie: реализации НЕ ДОЛЖНЫ хранить токены на предъявителя в файлах cookie, которые могут быть отправлены в открытом виде (который является режимом передачи по умолчанию для файлов cookie). Реализации, которые хранят токены на предъявителя в файлах cookie, ДОЛЖНЫ принимать меры предосторожности против подделки межсайтовых запросов.
Краткосрочный токен
Выдавать токены на предъявителя с коротким сроком действия: серверы токенов ДОЛЖНЫ выдавать токены на предъявителя с коротким сроком действия (один час или меньше), особенно при выдаче токенов клиентам, которые работают в веб-браузере или других средах, где может произойти утечка информации. Использование недолговечных токенов на предъявителя может уменьшить влияние их утечки.
Теперь проверяем документацию Bigquery по этой ссылке
Их рекомендация такова: сохраните токены обновления в безопасном долговременном хранилище, которые обычно не выполняются в среде хранения на стороне клиента.
Поскольку вы всегда получаете токен обновления из BigQuery OAuth2 API, вы можете использовать его во всех своих вызовах API, выполняемых на стороне сервера, тем самым предоставляя пользователю беспрепятственный безопасный поток. Проверьте это в Google oauthplayground
Кстати: обычно вызов со стороны клиента выполняется по соображениям производительности, в случае BigQuery, поскольку это решение для обработки больших данных, я чувствую, что дополнительные несколько секунд, связанные с вызовами на стороне сервера, менее важны
Комментарии:
1. Я проверю еще раз, но AFAIK, приложения не получают токены обновления, если они не запрашивают разрешение на автономный доступ
2. Я добавил немного больше деталей к своему ответу. В любом случае, я не думаю, что вам следует хранить информацию о токене обновления / долгосрочном доступе на стороне клиента, надеюсь, это имеет смысл для вас
3. Привет @OzgurAkcali, хотел узнать, помог ли вам мой ответ каким-либо образом?