получение client id и client secret для приложений использующих google
Инструкция с картинками: где взять Clinet ID и Client Secret для Oauth2-авторизации через Google+?
Для Oauth2-авторизации на вашем сайте при помощи зарубежной социальной сети «Google+» вам понадобятся Clinet ID и Client Secret.
Помните! Clinet ID и Client Secret — это секретная информация! Её нельзя публиковать, это запрещено правилами Гугла. Поэтому, кстати, все данные на скриншотах я заменил на фиктивные — не пытайтесь их никуда скопировать, не сработает.
Для начала убедитесь, что у вас есть аккаунт в Гугл. Если у вас уже есть Gmail или аккаунт на Youtube, то, значит, есть и аккаунт в Google, так как он един для всех сервисов этой компании. Если же нет, то вначале зарегистрируйтесь (ссылка «Создать аккаунт»). При регистрации я бы рекомендовал указывать ваши реальные фамилию, имя, отчество, действительный номер телефона и загрузить фотографию. Всё-таки, случись что, если у вас указаны реальные данные, вы сможете, связавшись с администрацией ресурса, подтвердить, что являетесь владельцем аккаунта (по крайней мере, будет больше на то шансов).
Имея аккаунт в Google, вы теперь можете приступить к созданию приложения для Oauth2-авторизации и получению Clinet ID и Client Secret.
1. Сначала зайдите в консоль разработчиков Гугла. Если вы там впервые, вам предложат зарегистрироваться. Следуйте инструкциям. После этого вы попадёте на дэшборд.
2. На дэшборде нажмите на Create Project.
Если вы не в том разделе, то сначала нажмите на Projects
3. Заполните форму. Обратите внимание, что в названии нельзя использовать русские буквы. Я выбрал название «Maslov-5 Development Server». Проекту будет автоматически присвоен id. У гугла они в виде словосочетаний. Например, мне выпало «coral-atom-803». Можете пощёлкать на иконку «Обновить» справа от неё, чтобы подобралось другое. Обязательно отметить галочку, если она у вас есть. Нажмите Create.
4. Теперь слева нажимаем на APIs & Auth, и в нём на Credentials.
5. В нём под разделом OAuth на Create new Cliend ID.
6. В появившемся окошке выбираем Web Application. От нас хотят узнать дополнительные данные. Нажимаем на Configure consent screen.
7. Нас перекидывает на настройки. Нужно указать ваш емейл и имя приложения (как оно будет показываться посетителю, теперь можно и по-русски, я написал «Сервер разработки Маслов-5»). Заполняем и жмём Save.
8. Снова попадаем на окно создания Client ID. На этот раз нам предлагают ввести Authorised javascript origins (обычно это адрес сайта) и Authorised redirect uris для oauth2.
В моём случае это «http://dev5.maslov.co/» и «http://dev5.maslov.co/user/index/sociallogin/provider/g/» соответственно.
Вводим и, наконец, жмём на Create Client ID.
9. Система призадумается на какое-то время, а затем, возможно, снова покажет нам окошко этих же настроек. Позади него уже видны нужные нам данные! Окошко, если оно появилось, можно закрыть кнопкой Cancel.
Вопрос к следующему этой инструкции: на пункте 9 появилось ли окошко? У меня первый раз появилось, а когда регал второй сайт— нет.
10. А вот за этим-то мы и пришли! Я не имею права публиковать свои Clinet ID и Client Secret, поэтому на скриншоте я их скрыл.
Готово! Теперь у вас есть Clinet ID и Client Secret, используйте их по назначению!
You can leave a comment with «Facebook»:
Блог Ягнёнка
Получение client id и client secret для приложений использующих Google
Подключал тут недавно социальную авторизацию на нескольких своих сайтах и пришлось получать client id и client secret ключи от Google. О том, как это сделать быстро и без лишних движений в этом небольшом посте. Google в панели облачного API постоянно что-то накручивает, меняет местами пункты меню, поэтому на постоянную актуальность не претендую, а всего лишь держу как шпаргалку, когда в очередной раз придется обратиться.
Далее надо придумать название проекта, идентификатор же и прочую лабуду Google придумает сам. Жмем создать.
Дальше нужно в нашем проекте создать собственно сами ключи. Для этого находим пункт меню Включить API и создать ключи.
Он предложит нам создать учетные данные, создаем куда нам деваться. За этим же и пришли.
В моем случае я буду использовать ключи для веб-приложения авторизации на своем блоге, поэтому выбираю его.
Нужно будет ввести название, и адрес куда перенаправлять полученные данные от сервиса. Я отправляю все в плагин авторизации на своем блоге. Далее опять жмем создать.
И собственно в итоге получаем наконец свои заветные ключи.
Не могу найти. Хочу добавить на сайт авторизацию через соц. сети. Для возможности авторизации через facebook, twitter, google требуется cliend_id и client_secret.
Как и где добавить приложение и получить client_id и client_secret для OAuth twitter, google, fb?
2 ответа
1. Facebook add app
2. Google add app
Добавить приложение в google developers проще всего через консоль:
3. Twitter add app
Добавить twitter приложение можно тут:
Список доступных twitter приложений:
Более подробно о получении google app key. Для авторизации через google на веб-сайте, добавляем google веб-приложение через google-консоль и получаем для него Client ID и Client secret.
1. Нужно перейти на url https://console.developers.google.com/. Авторизоваться и добавить новый проект. Кнопка Create Project.
2. Указать имя проекта и нажать Create.
После нажатия Configure consent screen приложение будет успешно добавлено.
4. Генерируем Client ID и Client Secret для нашего приложения. Для этого заходим на вкладку APIs & auth и там выбираем Credentials. Нажимаем кнопку Create new Client ID.
5. На этой же вкладке Credentials копируем к себе значения Client ID и Client secret.
UPD: в конце 2015г. google изменил дизайн для Developer Console. По-прежнему нужно искать ссылку Credentials, только добраться до неё стало немного труднее. А может я просто не привык еще.
Create credentials
Credentials are used to obtain an access token from a Google authorization server. This token is used to call Google Workspace APIs. The type of credentials you use depends on the type of data your app accesses. All Google Workspace APIs access data owned by an end-user. You can use either an OAuth client ID or a service account with domain delegation of authority to access user data.
Configure the OAuth consent screen
When you use OAuth 2.0 for authorization, your app requests authorizations for one or more scopes of access from a Google Account. Google displays a consent screen to the user including a summary of your project and its policies and the requested scopes of access. You must configure the consent screen for all apps. However, you need only list scopes used by your app for external apps.
To configure the OAuth consent screen:
Click the user type for your app. If you’re running a Quickstart, select Internal.
Click Create. A second «OAuth consent screen» screen appears.
Click Save and Continue. The «Scopes» page appears.
(optional). If you are creating an external app, click Add or Remove Scopes. The «Update selected scopes» page appears.
(optional). For each API you intend to use in your app, check the scopes to use in your app.
(optional) Click Update. A list of scopes for your app appears. If any scopes appear under the heading «Your sensitive scopes» or «Your restricted scopes,» refer to Identify scopes.
Click Save and Continue. The «Edit app registration» page appears.
Click Save and Continue. The «OAuth consent screen» appears.
Click Back to Dashboard.
If you are creating a service account with domain-wide delegation of authority, proceed to Create a service account with domain-wide delegation.
Create a OAuth client ID credential
Click the Application type drop-down list and select the type of application you’re creating. For a full explanation of application types, refer to Setting up OAuth 2.0.
In the name field, type a name for the credential. This name is only shown in the Cloud Console.
In this document, continue with the documentation that corresponds to your app type:
Create Web application credentials (client-side JavaScript)
If you’re creating Web application credentials for a client-side JavaScript app, follow these steps :
Create Web application credentials (web server app)
If you’re creating Web application credentials for a web server app, follow these steps :
Create Desktop application credentials
If you’re creating Desktop application credentials:
Create Chrome application credentials
If you’re creating Chrome application credentials:
Create Android application credentials
If you’re creating Android application credentials:
Create iOS application credentials
If you’re creating iOS application credentials:
Create TVs and limited input device credentials
If you’re creating Chrome application credentials:
Create Universal Windows Platform (UWP) credentials
If you’re Universal Windows Platform (UWP) creating Universal Windows Platform (UWP) credentials:
Create a service account with domain-wide delegation of authority
Creating a service account with domain-wide delegation of authority is a three-step process:
Create a service account
Obtain service account credentials
You must obtain credentials in the form of a public/private key pair. These credentials are used by your code to authorize service account actions within your app. To obtain credentials for your service account:
Grant access to user data to a service account
To access user data on a Google Workspace domain, the service account that you created needs to be granted access to user data through an API. This process must be performed by a super administrator for the domain. To grant your service account access to user data:
Your service account now has domain-wide access to your enabled Workspace API(s) for all the users of your domain.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Аутентификация OAuth2 в приложении посредством Google Sign-In. Непрерывный доступ к API Google
«С 20 апреля 2017 года отправка запросов на авторизацию из встроенных браузеров будет блокироваться».
Такое сообщение с 1 марта можно увидеть в некоторых приложениях, где необходима авторизация. Об этом Google написали в своём блоге еще в августе 2016, и это значит, что скоро во многих приложениях придется переписывать реализацию регистрации. Приятного мало, однако выход есть – использовать рекомендуемый способ авторизации Google Sign-in.
Об этом способе и будет идти речь в уроке, а также как получить токены, необходимые для работы с API Google.
В уроке будет присутствовать частичный перевод официальных документаций. Но сперва немного предыстории из моей практики и первой работы с OAuth2, возможно кто-то окажется в похожей ситуации.
Понадобилось мне для приложения получить чат с прямой трансляции YouTube. И тогда я узнала, что для отправки запросов на получение трансляции (и только потом чата) необходимо провести OAuth2 аутентификацию пользователя. Я начала искать. Информации по такой теме очень мало, она разрознена, не подходила для моего случая, и конечно же всё было на английском языке. В основном информация была для работы с наиболее популярными API: Drive, Cloud, Google Plus. В официальной документации API YouTube есть готовый код, бери да пользуйся, однако для Android он не подходит. Потратив немалое количество времени, методом проб и ошибок я пришла к рабочему решению. Первое, что мне захотелось сделать после, это собрать информацию «в кучу» и разложить по полочкам, что и сподвигло на написание этого урока.
Изначально моё решение начиналось с того, что перед пользователем открывался WebView для авторизации (ввод email, пароля). Далее запрашивалось разрешение на использование данных, и только после разрешения в ответе приходил код аутентификации (AuthCode), подробнее что с ним делать будет далее. Url, который открывался в WebView был следующий:
Это ни что иное, как post запрос, в ответ на который приходила страница, содержащая authCode, причем код был в заголовке страницы. Всё, как по рекомендации к API, а действия для сокрытия этого кода от пользователя оставили на разработчика.
Всё работало хорошо, приложение опубликовано, но в один прекрасный день я увидела следующее:
Перейдя по ссылке «Подробнее» попадаем в блог, где сказано, что во имя безопасности, аутентификация через WebView работать не будет с 20 апреля. Ну вот, думаю я, только сделала и придется переделывать через Sign-In. Причем первоначально я пыталась сделать реализацию именно через этот сервис. Однако с уже имеющимися знаниями «что и зачем» получилось довольно быстро. И так, начнем.
1. Получение учетных данных
В Диспетчере API создаем новый проект (или выбираем существующий):
Для авторизации понадобится файл конфигурации, который можно получить в мастере:
Заполняем поля название приложения и пакет. Далее выбираем какой сервис подключаем (Google Sign-In), здесь нужно ввести SHA1 ключ приложения, получить его просто: в Android Studio находим вкладку Gradle, раскрываем вкладки Tasks-android-signingReport. Щелкаем два раза, и в логах появится информация о ключах. Находим ключ SHA1, копируем.
Жмем кнопку «Generate configuration file», а после «Download google-services.json». Этот файл json сохраняем в папку проекта «app».
Важно! Если вы собираетесь публиковать приложение в Google Play, debug ключ SHA1 нужно будет заменить на release ключ, соответственно и заменить файл конфигурации.
Заходим в Диспетчер API, видим, что сгенерировались ключи и идентификаторы клиентов OAuth. Нам понадобятся только данные Web client (идентификатор клиента и секрет клиента).
Во вкладке «Окно запроса доступа OAuth» можно поменять email и название продукта — это то, что будет написано, когда будет запрашиваться разрешение «Приложение **** запрашивает: …»
2. Настройка Sign-In клиента
Чтобы получить доступ к Google Api Client, в файл gradle app нужно добавить в зависимости:
И плагин (в конец файла):
В файл gradle project в зависимости:
Здесь наибольший интерес вызывают строки:
requestServerAuthCode(getString(R.string.server_client_id)) – запрашиваем authCode, передавая параметр идентификатор клиента (весь полностью), который получили выше.
requestScopes(new Scope(«***»)) – запрашиваем необходимую для используемого API область/области доступа. Есть некоторые уже определенные области в Scopes, но, если нужной там не нашлось, можно задать свою, как в моём случае. Для пользователя будет отображаться как доступ «к чему» хочет получить приложение.
Тут всё по стандарту из документации:
enableAutoManage(this, this) – в параметры передается активити и слушатель соединения (реализуем интерфейс GoogleApiClient.OnConnectionFailedListener).
addApi(Auth.GOOGLE_SIGN_IN_API, gso) – указываем, что используем Sign In api и ранее созданный объект опций.
Теперь для запуска авторизации нужна кнопка (либо любой другой элемент). Можно использовать стандартную кнопку Sign In Button. Разметка xml:
В активити кнопка определяется как и все другие view, на нее повешаем слушатель и по клику выполним метод:
Код вызываемого метода представляет собой создание интента и вызов активити для авторизации:
В параметр передаем сконфигурированный mApiClient. RC_AUTH_CODE любое число, как и всегда, для отслеживания результата активити.
При нажатии на копку, будет предложено выбрать аккаунт для входа, либо добавить новый. После выбора, приложение запросит разрешение:
3. Получение Auth code
После того, как пользователь даст разрешение, в onActivityResult получаем данные его аккаунта:
В результате получаем auth code как обычную строку, выглядит он примерно так:
Так же из аккаунта можно получить email пользователя, username и аватарку:
acct.getEmail()
acct.getDisplayName()
acct.getPhotoUrl()
Эти данные могут понадобиться, например, чтобы вставить их в header NavigationView.
4. Получение Access Token и Refresh Token
Получили auth code, теперь его нужно поменять на необходимые для запросов к API токены. Для этого формируем запрос по адресу https://www.googleapis.com/oauth2/v4/token. Например я сделаю это с помощью OkHttp.
Рассмотрим подробнее параметры. В Request.Builder() Передаем url по которому получаем токены:
В header указываем Content-Type:
Указываем, что это метод POST, в него передаем body:
Сформированный requestBody обязательно должен содержать параметры:
«grant_type», «authorization_code» – указываем, что передавать будем auth code
«client_id», getString(R.string.server_client_id) – параметр является client id, полученный в Диспетчере API
«client_secret», getString(R.string.client_secret) — секрет клиента, полученный в Диспетчере API
«code», authCode – собственно полученный код.
Запрос асинхронный, в ответе получаем обычный json со всеми нужными для работы данными:
«access_token» – токен доступа, ради которого всё проводилось
«expires_in» – время жизни access токена, по умолчанию токен живет 1 час, а в сутки можно получать по запросу 25 токенов, не более.
«token_type» – тип токена, его тоже необходимо запомнить, он также вставляется в запрос к api в дальнейшем.
«refresh_token» – токен для обновления access токена, когда пройдет час жизни. Refresh токен неизменен. Часто на форумах видела проблему, с которой сталкивалась и сама: в запросе не приходил этот токен. Ошибки заключаются в неправильном получении учетных данных, либо неправильные запросы. Если авторизация проводилась через WebView, и в url не указывался такой важный параметр как access_type=offline, то refresh токен попросту не приходил.
5. Обновление Access токена
Час прошел, access токен больше не активен, необходим новый. После этого посыпятся ошибки 401 или 403, сервер скажет, что пользователь не авторизован или не имеет доступа. Запрашивать новое разрешение не годится, если нам нужна непрерывная сессия, например как у меня, нужно непрерывно получать сообщения из чата в течении трансляции, а это несколько часов. Что делать? Посылать запрос на получение нового токена.
Запрос в основном такой же как в пункте 4, за исключением некоторых параметров:
Здесь важные параметры:
«grant_type», «refresh_token» – в типе указываем что посылаем refresh токен
«refresh_token», mRefreshToken – и сам токен
Ответом будет json, содержащий новый access токен, с которым снова можно обращаться к API:
На этом авторизация и аутентификация пользователя завершена.
Для примера покажу как выглядит запрос к API, а также как я выполняю обновление токена.
Для запроса к API я использую Retrofit2 + RxAndroid. Так выглядит запрос на получение чата прямой трансляции:
Здесь важно заметить, что в header по ключу Authorization должны передаваться тип токена и сам access токен. То есть так:
Далее делаю запрос через RxAndroid, и так как в коллбэк onError приходят всевозможные ошибки, то туда же приходит ошибка HttpException с кодом 401 Unauthorized по истечении часа. Здесь же я обрабатываю её, проверяю, если это та самая ошибка, то привожу к соответствующему типу, проверяю действительно ли это код 401 и выполняю метод получения нового токена, затем повторяю запрос.
Так же для проверки токена существует GET запрос:
В ответ придут данные о токене, если он еще активен, либо ошибка, если его время жизни истекло.
Опять же, реализацию обновления токена Google оставляет на разработчика.
Выйти из аккаунта и отозвать авторизацию намного проще, в официальной документации найти не составит труда, если понадобится.
Рекомендую перед началом работы проверять запросы в стороннем приложении/расширении, например Postman, чтобы убедиться в правильности ввода параметров и полученных ответах. Я буду очень рада, если кому-то урок окажется полезным!