Concesión de código de autorización
-
Solicitud de autorización
-
La aplicación primero debe decidir qué permisos solicita y luego enviar al usuario a un navegador para obtener su permiso. Para iniciar este flujo de autorización, cree una URL como se muestra a continuación y redirija el navegador del usuario final a la 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>
tipo_respuesta=código: El tipo de respuesta que espera. Para recibir el código de autorización debe tener valor.
código. Esto le indica al servidor de autorización que la aplicación está iniciando el flujo de autorización.
Identificación del cliente : El ID de cliente proporcionado por el proveedor de OAuth.
redirección_uri: URL de devolución de llamada a la que el usuario será redirigido una vez que permita o no permita el acceso a su aplicación.
alcance : Una o más cadenas separadas por espacios que indican el permiso que solicita su aplicación.
Expresar : La aplicación genera una cadena aleatoria y la incluye en la solicitud. Luego debe verificar que se devuelva el mismo valor después de que el usuario autoriza la aplicación.
Si el usuario permite el acceso a su aplicación, su navegador será redirigido a la URL de redireccionamiento proporcionada y la solicitud incluirá
código y estado parámetros en la cadena de consulta.
Por ejemplo, el usuario puede ser redirigido a una URL como
https://example-app.com/redirect
?code=<authorization-code>
&state=<security_token>
El código es un código de autorización que se puede canjear por un token de acceso. Lo genera el servidor de autorización y tiene una duración relativamente corta.
El estado es el mismo token de seguridad que la aplicación estableció inicialmente en la solicitud.
Solicitud de token
-
Si el usuario final concedió acceso a su aplicación y usted recibe un código de autorización, puede intercambiar el código de autorización por un token de acceso realizando una solicitud POST al punto final del token.
- El siguiente es un ejemplo de solicitud POST:
PUBLICAR 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>
Aquí está la descripción de cada parámetro de solicitud.
-
Grant_type=código_autorización: El tipo de subvención que está proporcionando. Esto indica que la aplicación está utilizando el tipo de concesión de código de autorización.
-
código: El código de autorización recibido en el paso anterior, incluido aquí.
-
redirigir_uri: El mismo uri que se proporcionó anteriormente en la solicitud de autorización.
-
Identificación del cliente : El ID de cliente proporcionado por el proveedor de OAuth.
-
secreto_cliente: El secreto del cliente proporcionado por el proveedor de OAuth.
En el punto final del token se verificarán todos los parámetros de la solicitud, asegurando que el código no haya caducado y que la identificación del cliente y el secreto coincidan. Si la Solicitud tiene éxito, generará un token de acceso y lo devolverá en la respuesta:
HTTP/1.1 200 OK Tipo de contenido: aplicación/json Control de caché: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bearer", "expires_in":3600, "scope":"profile", "id_token":"" }
Aquí está la descripción de cada parámetro recibido en la respuesta.
-
token_acceso: token de acceso para el punto final de información de usuario.
-
tipo_token: Valor del tipo de token de OAuth 2.0. El valor debe ser Portador.
-
expira en : El tiempo de vencimiento del token de acceso.
-
alcance: Una o más cadenas separadas por espacios que indican el permiso que solicita su aplicación.
-
token_id: El token de identificación es un token de seguridad que contiene reclamaciones sobre la autenticación de un usuario final por parte de un servidor de autorización cuando se utiliza un cliente y, potencialmente, otras reclamaciones solicitadas.
Si la solicitud falla la respuesta tendrá un estado de
404 Bad Request y tendrá el siguiente contenido:
"error": "invalid_request", "error_description": "Una descripción más detallada del error destinada al desarrollador de su aplicación".
Solicitud de recursos
-
Si la solicitud del token tiene éxito, obtendrá
access_token en la respuesta que se puede utilizar para acceder a los recursos protegidos a través de la API.
-
Solicitud de información de usuario: El siguiente es un ejemplo no formativo de Solicitud de información de usuario:
http://<wp_base_url>/wp-json/moserver/resource
Host: server.example.com
Authorization: Bearer <access_token>
El servidor de recursos valida y verifica el token de acceso y comprueba si no ha caducado. Si la solicitud de recursos es válida, el servidor de recursos devuelve los reclamos que están representados por un objeto JSON que contiene una colección de pares de nombre y valor para los reclamos.
Respuesta exitosa de información de usuario:
Los UserInfo Claims DEBEN devolverse como miembros de un objeto JSON.
A continuación se muestra el ejemplo:
{ "id": "1", "nombre de usuario": "abc", "first_name": "xyz", "last_name": "ejemplo", "imagen": "https://example.com/-kwtzesU/photo .jpg", "correo electrónico": "abc@example.com", "locale": "en",... }
Concesión de código implícito
-
Solicitud de autorización
-
La aplicación primero debe decidir qué permisos solicita y luego enviar al usuario a un navegador para obtener su permiso. Para iniciar este flujo implícito, cree una URL como se muestra a continuación y redirija el navegador del usuario final a la URL:
Recibe 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>
tipo_respuesta=token: El tipo de respuesta que espera. Esto le indica al servidor de autorización que la aplicación está iniciando un flujo implícito. Tenga en cuenta la diferencia con el flujo del Código de autorización donde este valor se establece en código.
Identificación del cliente : El ID de cliente proporcionado por el proveedor de OAuth.
redirección_uri: URL de devolución de llamada a la que el usuario será redirigido una vez que permita o no permita el acceso a su aplicación.
alcance : Una o más cadenas separadas por espacios que indican el permiso que solicita su aplicación.
Expresar : La aplicación genera una cadena aleatoria y la incluye en la solicitud. Luego debe verificar que se devuelva el mismo valor después de que el usuario autoriza la aplicación.
Si el usuario permite el acceso a su aplicación, su navegador será redirigido a la URL de redireccionamiento proporcionada y la solicitud incluirá
ficha y estado parámetros en la cadena de consulta.
Por ejemplo, el usuario puede ser redirigido a una URL de devolución de llamada como
https://callback-url?
#access_token=<access_token>
&token_type=Bearer
&expires_in=3600
&scope=<permissions_requesting>
Tenga en cuenta las dos diferencias principales entre este y el flujo del Código de autorización: se devuelve el token de acceso en lugar del código de autorización en la respuesta.
El cliente puede entonces utilizar el access_token para acceder a recursos protegidos desde el servidor de recursos.
Aquí está la descripción de cada parámetro recibido en la respuesta.
-
token_acceso: token de acceso para el punto final de información de usuario.
-
tipo_token: Valor del tipo de token de OAuth 2.0. El valor debe ser Portador.
-
expira en : El tiempo de vencimiento del token de acceso.
-
alcance: Una o más cadenas separadas por espacios que indican el permiso que solicita su aplicación.
Solicitud de recursos
-
El punto final UserInfo es un recurso protegido de OAuth 2.0 que devuelve reclamaciones sobre el usuario final autenticado. Los Claims devueltos están representados por un objeto JSON que contiene una colección de pares de nombre y valor para los Claims.
-
Solicitud de información de usuario: El siguiente es un ejemplo no formativo de Solicitud de información de usuario:
http://<wp_base_url>/wp-json/moserver/resource
Host: server.example.com
Authorization: Bearer <access_token>
Respuesta exitosa de información de usuario:
Los UserInfo Claims DEBEN devolverse como miembros de un objeto JSON.
A continuación se muestra el ejemplo:
{ "id": "1", "nombre de usuario": "abc", "first_name": "xyz", "last_name": "ejemplo", "imagen": "https://example.com/-kwtzesU/photo .jpg", "correo electrónico": "abc@example.com", "locale": "en",... }
Concesión de contraseña
-
El tipo de concesión de contraseña del propietario del recurso (o "contraseña") se utiliza principalmente en los casos en que la aplicación es altamente confiable. En esta configuración, el usuario proporciona sus credenciales del servidor de recursos (nombre de usuario/contraseña) a la aplicación cliente, que les envía una solicitud de token de acceso.
-
Solicitud de token
-
La concesión de contraseña es una de las concesiones de OAuth más simples e implica solo un paso: la aplicación presenta un formulario tradicional de inicio de sesión de nombre de usuario y contraseña para recopilar las credenciales del usuario y realiza una solicitud POST al servidor para intercambiar la contraseña por un token de acceso. La solicitud POST que realiza la aplicación se parece al ejemplo siguiente.
PUBLICAR 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
Los parámetros POST en esta solicitud se explican a continuación.
-
concesión_tipo=contraseña: Esto le indica al servidor que estamos usando el tipo de concesión de contraseña.
-
nombre de usuario = El nombre de usuario del usuario que ingresó en la aplicación.
-
password = La contraseña del usuario que ingresó en la aplicación.
-
id_cliente= El identificador público de la aplicación que el desarrollador obtuvo durante el registro.
-
cliente_secreto= El secreto del cliente proporcionado por el proveedor de OAuth.
En el punto final del token se verificarán todos los parámetros de la solicitud, asegurando que el código no haya caducado y que la identificación del cliente y el secreto coincidan. Si la Solicitud tiene éxito, generará un token de acceso y lo devolverá en la respuesta:
HTTP/1.1 200 OK Tipo de contenido: aplicación/json Control de caché: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bearer", "expires_in":3600, "scope":"profile", "id_token":"" }
El cliente puede entonces utilizar el access_token para acceder a recursos protegidos desde el servidor de recursos.
Aquí está la descripción de cada parámetro recibido en la respuesta.
-
token_acceso: token de acceso para el punto final de información de usuario.
-
tipo_token: Valor del tipo de token de OAuth 2.0. El valor debe ser Portador.
-
expira en : El tiempo de vencimiento del token de acceso.
-
alcance: Una o más cadenas separadas por espacios que indican el permiso que solicita su aplicación.
Solicitud de recursos
-
El punto final UserInfo es un recurso protegido de OAuth 2.0 que devuelve reclamaciones sobre el usuario final autenticado. Los Claims devueltos están representados por un objeto JSON que contiene una colección de pares de nombre y valor para los Claims.
-
Solicitud de información de usuario: El siguiente es un ejemplo no formativo de Solicitud de información de usuario:
http://<wp_base_url>/wp-json/moserver/resource
Host: server.example.com
Authorization: Bearer <access_token>
Respuesta exitosa de información de usuario:
Los UserInfo Claims DEBEN devolverse como miembros de un objeto JSON.
A continuación se muestra el ejemplo:
{ "id": "1", "nombre de usuario": "abc", "first_name": "xyz", "last_name": "ejemplo", "imagen": "https://example.com/-kwtzesU/photo .jpg", "correo electrónico": "abc@example.com", "locale": "en",... }
Concesión de credenciales de cliente
-
La concesión de credenciales de cliente se puede utilizar para la autenticación de máquina a máquina. En esta concesión no se autoriza a un usuario específico sino que se verifican las credenciales y se devuelve un token de acceso genérico.
-
Solicitud de token
-
Para recibir un token de acceso, el cliente PUBLICA una llamada API con los valores de ID de cliente y secreto de cliente obtenidos de una aplicación de desarrollador registrada de la siguiente manera.
PUBLICAR 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>
Parámetros de solicitud:
- Los parámetros de la solicitud POST se explican a continuación.
-
Grant_type=credenciales_cliente: Esto le indica al servidor que estamos usando el tipo de concesión de credenciales de cliente.
-
id_cliente= El identificador público de la aplicación que el desarrollador obtuvo durante el registro.
-
secreto_cliente: El secreto del cliente proporcionado por el proveedor de OAuth.
-
redirección_uri: URL de devolución de llamada a la que el usuario será redirigido una vez que permita o no permita el acceso a su aplicación.
-
alcance : Una o más cadenas separadas por espacios que indican el permiso que solicita su aplicación.
Si las credenciales son válidas, la aplicación recibirá un token web JSON firmado o un token de acceso, el tipo de token (que es portador) y en cuánto tiempo caduca en tiempo Unix.
Respuesta de muestra
{ "token_acceso": , "expires_in": 600, "token_type": "Portador" }
Elementos de respuesta:
-
token_acceso: token de acceso para el punto final de información de usuario.
- expira en El tiempo de vencimiento del token de acceso.
-
tipo_token: Valor del tipo de token de OAuth 2.0. El valor debe ser Portador.
Solicitud de recursos
- El Concesión de credenciales de cliente no soporta Solicitud de recursos.
Actualizar concesión de token
-
Un token de actualización permite que la aplicación emita un nuevo token de acceso o token de identificación sin tener que volver a autenticar al usuario. Esto funcionará siempre y cuando el token de actualización no haya sido revocado.
-
Solicitud de token
-
La respuesta de la solicitud de token debe contener un token de acceso y un token de actualización.
{ "access_token": "etMv23....429hiU32Hri", "refresh_token": "GEbRxBN...edjnXbL", "token_type": "Portador" }
Utilice un token de actualización:
Para intercambiar el token de actualización que recibió por un nuevo token de acceso, realice una solicitud POST al punto final del token, usando
Grant_type=refresh_token como sigue.
PUBLICAR 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>
Aquí está la descripción de cada parámetro de solicitud.
-
Grant_type=refresh_token: Esto le indica al servidor que estamos usando el tipo de concesión de token de actualización.
-
id_cliente= El identificador público de la aplicación que el desarrollador obtuvo durante el registro.
-
secreto_cliente: El secreto del cliente proporcionado por el proveedor de OAuth.
- token_actualización: El token de actualización que se utilizará.
La respuesta incluirá un nuevo token de acceso, su tipo, su vida útil (en segundos) y los alcances otorgados. Si el alcance del token inicial incluía openid, entonces también habrá un nuevo token de identificación en la respuesta.
La respuesta contendrá los siguientes parámetros:
{ "access_token": "eyJ...MoQ", "expires_in": 86400, "alcance": , "id_token": "eyJ...0NE", "token_type": "Portador" }
Revocar un token de actualización
-
Dado que los tokens de actualización nunca caducan, es esencial poder revocarlos en caso de que se vean comprometidos.
-
Para revocar un token de actualización, puede enviar un PUBLICAR Solicite el punto final del token de la siguiente manera.
PUBLICAR 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>
Pase gratuito
Si no encuentra lo que busca, por favor contáctenos en
info@miniorange.com
o llámanos al +1 978 658 9387 para encontrar una respuesta a su pregunta sobre Wordpress OAuth Server.
Mira los vídeos para saber más.
Ver la demostración
