Предоставление кода авторизации
-
Запрос на авторизацию
-
Сначала приложению необходимо определить, какие разрешения оно запрашивает, а затем перенаправить пользователя в браузер для получения этих разрешений. Чтобы запустить этот процесс авторизации, сформируйте URL-адрес, как показано ниже, и перенаправьте браузер конечного пользователя на этот URL-адрес:
ПОЛУЧИТЬ http://<wp_base_url>/wp-json/moserver/authorize
?response_type=code
&client_id= <client_id_goes_here>
&redirect_uri= <callback_url>
&scope= <permissions_requesting>
&state= <security_token>
response_type=code : Тип ожидаемого ответа. Для получения кода авторизации он должен иметь значение.
кодЭто сообщает серверу авторизации, что приложение инициирует процесс авторизации.
client_id : Идентификатор клиента, предоставленный поставщиком OAuth.
redirect_uri : URL-адрес обратного вызова, на который пользователь будет перенаправлен после того, как разрешит или запретит доступ к вашему приложению.
объем : Одна или несколько строк, разделённых пробелами, указывающих на запрашиваемое вашим приложением разрешение.
состояние : Приложение генерирует случайную строку и включает её в запрос. Затем оно должно проверить, возвращается ли то же значение после авторизации приложения пользователем.
Если пользователь разрешит доступ к вашему приложению, его браузер будет перенаправлен на указанный URL-адрес перенаправления, и запрос будет включать в себя следующее:
код и состояние параметры в строке запроса.
Например, пользователя можно перенаправить обратно на URL-адрес, такой как:
https://example-app.com/redirect
?code=<authorization-code>
&state=<security_token>
код Это код авторизации, который можно обменять на токен доступа. Он генерируется сервером авторизации и имеет относительно короткий срок действия.
состояние Это тот же токен безопасности, который приложение изначально установило в запросе.
Запрос токена
-
Если конечный пользователь предоставил вашему приложению доступ и вы получили код авторизации, вы можете обменять этот код на токен доступа, отправив POST-запрос на конечную точку токена.
- Ниже приведён пример POST-запроса:
POST http://<wp_base_url>/wp-json/moserver/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=<authorization_code>&
client_id=<client_id>&
client_secret=<clientSecret>&
redirect_uri=<redirect_uri>
Здесь приведено описание каждого параметра запроса.
-
grant_type=authorization_code : Тип предоставляемого вами гранта. Это указывает на то, что в приложении используется тип гранта — код авторизации.
-
код: Код авторизации, полученный на предыдущем шаге, прилагается здесь.
-
redirect_uri: Тот же URI, который был указан ранее в запросе на авторизацию.
-
client_id : Идентификатор клиента, предоставленный поставщиком OAuth.
-
client_secret : Секретный ключ клиента, предоставленный поставщиком OAuth.
На конечной точке получения токена будут проверены все параметры запроса, чтобы убедиться, что код не истек и идентификатор клиента и секретный ключ совпадают. В случае успешного выполнения запроса будет сгенерирован токен доступа, который будет возвращен в ответе.
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bearer", "expires_in":3600, "scope":"profile", "id_token":"" }
Здесь приведено описание каждого параметра, полученного в ответе.
-
access_token : токен доступа для конечной точки Userinfo.
-
token_type : Значение типа токена OAuth 2.0. Значение должно быть податель.
-
expires_in : Срок действия токена доступа.
-
объем: Одна или несколько строк, разделённых пробелами, указывающих на запрашиваемое вашим приложением разрешение.
-
id_token: Идентификационный токен (ID Token) — это токен безопасности, содержащий утверждения (Claims) об аутентификации конечного пользователя сервером авторизации при использовании клиента, а также, возможно, другие запрошенные утверждения.
Если запрос не удастся, ответ будет иметь следующий статус:
404 Bad Request и будет содержать следующее:
"error" : "invalid_request", "error_description" : "Более подробное описание ошибки, предназначенное для разработчика вашего приложения."
Запрос ресурса
-
Если запрос токена будет успешным, вы получите
access_token в ответе, который можно использовать для доступа к защищенным ресурсам через API.
-
Запрос информации о пользователе: Ниже приведён неформатирующий пример запроса Userinfo:
ПОЛУЧИТЬ http://<wp_base_url>/wp-json/moserver/resource
Host: server.example.com
Authorization: Bearer <access_token>
Сервер ресурсов проверяет и подтверждает токен доступа, а также убеждается, что он не истек. Если запрос к ресурсу действителен, сервер ресурсов возвращает утверждения, представленные в виде объекта JSON, содержащего набор пар «имя-значение» для утверждений.
Успешный ответ от Userinfo:
Объекты UserInfo Claims ДОЛЖНЫ быть возвращены в виде элементов объекта JSON.
Ниже приведен пример:
{ "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo.jpg", "email": "abc@example.com", "locale": "en",... }
Предоставление неявного кода
-
Запрос на авторизацию
-
Сначала приложению необходимо определить, какие разрешения оно запрашивает, а затем перенаправить пользователя в браузер для получения этих разрешений. Чтобы инициировать этот неявный процесс, сформируйте URL-адрес, как показано ниже, и перенаправьте браузер конечного пользователя на этот URL-адрес:
Получите http://<wp_base_url>/wp-json/moserver/authorize
?response_type=token
&client_id= <client_id_goes_here>
&redirect_uri= <callback_url>
&scope= <permissions_requesting>
&state= <security_token>
response_type=token : Тип ожидаемого ответа. Это сообщает серверу авторизации, что приложение инициирует неявный поток. Обратите внимание на отличие от потока с кодом авторизации, где это значение установлено как code.
client_id : Идентификатор клиента, предоставленный поставщиком OAuth.
redirect_uri : URL-адрес обратного вызова, на который пользователь будет перенаправлен после того, как разрешит или запретит доступ к вашему приложению.
объем : Одна или несколько строк, разделённых пробелами, указывающих на запрашиваемое вашим приложением разрешение.
состояние : Приложение генерирует случайную строку и включает её в запрос. Затем оно должно проверить, возвращается ли то же значение после авторизации приложения пользователем.
Если пользователь разрешит доступ к вашему приложению, его браузер будет перенаправлен на указанный URL-адрес перенаправления, и запрос будет включать в себя следующее:
знак и состояние параметры в строке запроса.
Например, пользователя можно перенаправить обратно на URL-адрес обратного вызова, такой как:
https://callback-url?
#access_token=<access_token>
&token_type=Bearer
&expires_in=3600
&scope=<permissions_requesting>
Обратите внимание на два основных отличия этого подхода от подхода с кодом авторизации: в ответе возвращается токен доступа, а не код авторизации.
Затем клиент может использовать access_token для доступа к защищенным ресурсам с сервера ресурсов.
Здесь приведено описание каждого параметра, полученного в ответе.
-
access_token : токен доступа для конечной точки Userinfo.
-
token_type : Значение типа токена OAuth 2.0. Значение должно быть податель.
-
expires_in : Срок действия токена доступа.
-
объем: Одна или несколько строк, разделённых пробелами, указывающих на запрашиваемое вашим приложением разрешение.
Запрос ресурса
-
Конечная точка UserInfo — это защищенный ресурс OAuth 2.0, который возвращает утверждения о прошедшем аутентификацию конечном пользователе. Возвращаемые утверждения представлены в виде объекта JSON, содержащего коллекцию пар «имя-значение» для этих утверждений.
-
Запрос информации о пользователе: Ниже приведён неформатирующий пример запроса Userinfo:
ПОЛУЧИТЬ http://<wp_base_url>/wp-json/moserver/resource
Host: server.example.com
Authorization: Bearer <access_token>
Успешный ответ от Userinfo:
Объекты UserInfo Claims ДОЛЖНЫ быть возвращены в виде элементов объекта JSON.
Ниже приведен пример:
{ "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo.jpg", "email": "abc@example.com", "locale": "en",... }
Предоставление пароля
-
Тип предоставления доступа «пароль владельца ресурса» (или «password») чаще всего используется в случаях, когда приложению доверяют очень высоко. В этой конфигурации пользователь предоставляет свои учетные данные сервера ресурсов (имя пользователя/пароль) клиентскому приложению, которое отправляет ему запрос на получение токена доступа.
-
Запрос токена
-
Предоставление пароля — один из простейших способов предоставления доступа по протоколу OAuth, включающий всего один шаг: приложение отображает традиционную форму входа с именем пользователя и паролем для сбора учетных данных пользователя и отправляет POST-запрос на сервер для обмена пароля на токен доступа. POST-запрос, отправляемый приложением, выглядит примерно так, как показано в примере ниже.
POST http://<wp_base_url>/wp-json/moserver/token
Host: authorization-server.com
Content-type: application/x-www-form-urlencoded
grant_type=password
&username=exampleuser
&password=12345678
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx
Параметры POST-запроса в этом запросе описаны ниже.
-
grant_type=password : Это сообщает серверу, что мы используем тип предоставления доступа Password.
-
имя пользователя = Имя пользователя, которое он ввел в приложение.
-
пароль = Пароль пользователя, который он ввел в приложение.
-
client_id= Публичный идентификатор приложения, полученный разработчиком при регистрации.
-
client_secret= Секретный ключ клиента, предоставленный поставщиком OAuth.
На конечной точке получения токена будут проверены все параметры запроса, чтобы убедиться, что код не истек и идентификатор клиента и секретный ключ совпадают. В случае успешного выполнения запроса будет сгенерирован токен доступа, который будет возвращен в ответе.
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bearer", "expires_in":3600, "scope":"profile", "id_token":"" }
Затем клиент может использовать access_token для доступа к защищенным ресурсам с сервера ресурсов.
Здесь приведено описание каждого параметра, полученного в ответе.
-
access_token : токен доступа для конечной точки Userinfo.
-
token_type : Значение типа токена OAuth 2.0. Значение должно быть податель.
-
expires_in : Срок действия токена доступа.
-
объем: Одна или несколько строк, разделённых пробелами, указывающих на запрашиваемое вашим приложением разрешение.
Запрос ресурса
-
Конечная точка UserInfo — это защищенный ресурс OAuth 2.0, который возвращает утверждения о прошедшем аутентификацию конечном пользователе. Возвращаемые утверждения представлены в виде объекта JSON, содержащего коллекцию пар «имя-значение» для этих утверждений.
-
Запрос информации о пользователе: Ниже приведён неформатирующий пример запроса Userinfo:
ПОЛУЧИТЬ http://<wp_base_url>/wp-json/moserver/resource
Host: server.example.com
Authorization: Bearer <access_token>
Успешный ответ от Userinfo:
Объекты UserInfo Claims ДОЛЖНЫ быть возвращены в виде элементов объекта JSON.
Ниже приведен пример:
{ "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo.jpg", "email": "abc@example.com", "locale": "en",... }
Предоставление учетных данных клиента
-
Предоставление учетных данных клиента может использоваться для аутентификации между машинами. При таком предоставлении авторизация конкретного пользователя не производится, вместо этого проверяются учетные данные, и возвращается общий токен доступа.
-
Запрос токена
-
Для получения токена доступа клиент отправляет POST-запрос к API, используя значения идентификатора клиента и секретного ключа клиента, полученные от зарегистрированного приложения разработчика, следующим образом.
POST http://<wp_base_url>/wp-json/moserver/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&
client_id=<client_id>&
client_secret=<clientSecret>&
redirect_uri=<redirect_uri>&
scope=<permisssions_requested>
Параметры запроса:
- Параметры POST-запроса описаны ниже.
-
grant_type=client_credentials : Это сообщает серверу, что мы используем тип предоставления учетных данных клиента.
-
client_id= Общедоступный идентификатор приложения, полученный разработчиком в процессе регистрации.
-
client_secret: Секретный ключ клиента, предоставленный поставщиком OAuth.
-
redirect_uri : URL-адрес обратного вызова, на который пользователь будет перенаправлен после того, как разрешит или запретит доступ к вашему приложению.
-
объем : Одна или несколько строк, разделённых пробелами, указывающих на запрашиваемое вашим приложением разрешение.
Если учетные данные действительны, приложение получит в ответ подписанный JSON Web Token или токен доступа, тип токена (Bearer) и время его истечения в формате Unix.
Пример ответа
{ "access_token": , "expires_in": 600, "token_type": "Bearer" }
Элементы ответа:
-
access_token : токен доступа для конечной точки Userinfo.
- истекает Срок действия токена доступа.
-
token_type: Значение типа токена OAuth 2.0. Значение должно быть податель.
Запрос ресурса
- Предоставление учетных данных клиента не поддерживает Запрос ресурса.
Предоставление токенов обновления
-
Токен обновления позволяет приложению выдать новый токен доступа или идентификационный токен без необходимости повторной аутентификации пользователя. Это будет работать до тех пор, пока токен обновления не был отозван.
-
Запрос токена
-
В ответе на запрос токена должны содержаться токен доступа и токен обновления.
{ "access_token": "etMv23....429hiU32Hri", "refresh_token": "GEbRxBN...edjnXbL", "token_type": "Bearer" }
Используйте токен обновления:
Чтобы обменять полученный токен обновления на новый токен доступа, отправьте POST-запрос к конечной точке токена, используя
grant_type=refresh_token а именно:
POST http://<wp_base_url>/wp-json/moserver/token
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&
client_id=<client_id>&
client_secret=<client_secret>&
refresh_token=<refresh_token>
Здесь приведено описание каждого параметра запроса.
-
grant_type=refresh_token : Это сообщает серверу, что мы используем тип предоставления токена обновления.
-
client_id= Общедоступный идентификатор приложения, полученный разработчиком в процессе регистрации.
-
client_secret: Секретный ключ клиента, предоставленный поставщиком OAuth.
- refresh_token : Токен обновления для использования.
В ответ будет включен новый токен доступа, его тип, срок действия (в секундах) и предоставленные области действия. Если область действия исходного токена включала openid, то в ответе также будет новый токен идентификатора.
Ответ будет содержать следующие параметры:
{ "access_token": "eyJ...MoQ", "expires_in": 86400, "scope": , "id_token": "eyJ...0NE", "token_type": "Носитель" }
Отозвать токен обновления
-
Поскольку токены обновления никогда не истекают, крайне важно иметь возможность отозвать их в случае компрометации.
-
Для отзыва токена обновления можно отправить POST Запрос к конечной точке токена выглядит следующим образом.
POST http://<wp_base_url>/wp-json/moserver/token
Content-Type: application/x-www-form-urlencoded
client_id=<client_id>&
client_secret=<client_secret>&
refresh_token=<refresh_token>
Попробуйте!
Если вы не нашли то, что искали, свяжитесь с нами по адресу
info@miniorange.com
или позвоните нам по телефону +1 978 658 9387 чтобы найти ответ на ваш вопрос о сервере OAuth для WordPress.
Посмотрите видео, чтобы узнать больше.
Смотреть демо
