Uso de OAuth 2 para acceder a la API de REST
La API de REST de los dominios de identidad soporta puntos finales compatibles con SCIM 2.0 con esquemas de núcleo estándar SCIM 2.0 y extensiones de esquema de Oracle para gestionar mediante programación usuarios, grupos, aplicaciones y funciones de identidad, como la gestión de contraseñas y las tareas administrativas. Para realizar llamadas de API de REST al dominio de identidad, necesita un token de acceso OAuth2 para utilizarlo para la autorización. El token de acceso proporciona una sesión (con ámbito y caducidad) que la aplicación cliente puede utilizar para realizar tareas en un dominio de identidad.
El siguiente diagrama de secuencia ilustra un ejemplo básico del flujo de autorización OAuth 2.0 para acceder a la API de REST de los dominios de identidad.
Utilice parámetros específicos de OAuth 2.0 al trabajar con un dominio de identidad. En la siguiente tabla, se describen los parámetros más comunes.
| Parámetro | Valor | Comentarios |
|---|---|---|
|
Cabecera de autorización |
Básico <base64_clientid_secret> |
El cliente lo utiliza como esquema de autenticación básica para transmitir el token de acceso en una cabecera. El valor del token de acceso debe ser un valor codificado en UTF-8 base64 del ID de cliente y el secreto de cliente concatenado con dos puntos como separador, por ejemplo, clientID:clientSecret. |
|
ID de cliente |
<client_id> |
Necesario. Una "clave de API" única que se genera al registrar la aplicación en la consola del dominio de identidad. |
|
Secreto de cliente |
<client_secret> |
Necesario. Clave privada similar a una contraseña que se genera al registrar la aplicación en la consola del dominio de identidad. No comparta este valor. |
|
URL de Token de Acceso |
/oauth2/v1/token |
Punto final utilizado para obtener un token de acceso del dominio de identidad. |
|
URL de autorización |
/oauth2/v1/authorize |
Punto final utilizado para obtener un código de autorización de los dominios de identidad y, a continuación, utilizado durante un flujo OAuth de 3 partes. |
|
Tipo de permiso |
client_credentials |
Necesario. Significa que la API de REST que se llama es propiedad de la aplicación cliente. |
|
Alcance (obligatorio) |
urna:opc:idm:__myscopes__ |
Este ámbito devuelve todos los permisos otorgados a la aplicación; si es necesario, se podrían utilizar otros ámbitos para obtener permisos específicos. |
Paso 1: Registro de una aplicación confidencial en dominios de identidad mediante la consola
Al registrar una aplicación confidencial en la consola del dominio de identidad, obtiene algunos de los parámetros clave que necesita para trabajar con OAuth 2.0: ID de cliente, secreto de cliente y ámbitos. OAuth 2.0 es un estándar para implementar la autorización delegada y la autorización se basa en el token de acceso necesario para acceder a un recurso. El token de acceso se puede emitir para un ámbito determinado, que define lo que puede hacer el token de acceso y a qué recursos puede acceder. Al registrar una aplicación web en un dominio de identidad, agrega ámbitos. En el siguiente ejemplo, se agregan los ámbitos necesarios para solicitar búsquedas, ediciones, creaciones y supresiones del usuario. Sin embargo, si tuviera que realizar otras acciones, por ejemplo, gestionar eventos de auditoría, eso requeriría otros ámbitos.
Para crear y registrar una aplicación confidencial, acceda a la consola de OCI y, a continuación, realice los siguientes pasos:
- Abra el menú de navegación y seleccione Identidad y seguridad. En Identidad, seleccione Dominios.
- Haga clic en el nombre del dominio de identidad en el que desea trabajar. Puede que necesite cambiar el compartimento para buscar el dominio que desee. A continuación, haga clic en Aplicaciones integradas.
- Seleccione Agregar aplicación.
- En el cuadro de diálogo Agregar aplicación, seleccione Aplicación confidencial y, a continuación, seleccione Iniciar flujo de trabajo.
- En la página Agregar detalles de aplicación, introduzca un nombre y una descripción de la aplicación y, a continuación, seleccione Siguiente.
- En la página Configurar OAuth, en Configuración de cliente, seleccione Configurar esta aplicación como un cliente ahora.
- En Autorización, seleccione solo Credenciales de cliente como Tipo de permiso permitido.
- En la parte inferior de la página, seleccione Agregar roles de aplicación y, a continuación, seleccione Agregar roles.
- En el panel Agregar roles de aplicación, seleccione Administrador de dominio de identidad y, a continuación, seleccione Agregar.
- Seleccione Siguiente y, a continuación, seleccione Terminar.
- En la página del detalle de la aplicación, desplácese hacia abajo hasta Información general. Copie el ID de cliente y el Secreto de cliente y almacénelo en un lugar seguro.
- Después de crear la aplicación, seleccione Activar.
Paso 2: Base64 Codificar el ID y el secreto del cliente
Antes de la codificación base64, la URL individual codifica el ID de cliente y el secreto de cliente. Si el ID de cliente y el secreto de cliente no contienen caracteres especiales, no es necesario que los codifique primero mediante URL. Sin embargo, como mejor práctica, lo recomendamos encarecidamente.
Ventanas
-
Inicie el Bloc de notas y, a continuación, pegue la ID. de cliente y el secreto de cliente en el Bloc de notas.
-
Coloque el ID y el secreto de cliente en la misma línea e inserte dos puntos entre ellos:
clientid:clientsecretNota
Asegúrese de que no haya espacios en el atributo clientid:clientsecret. -
Guarde el archivo en
C:\tempy asígnele el nombreappCreds.txt. -
En el Explorador de Windows, haga clic con el botón derecho en
C:\tempy, a continuación, seleccione Petición de datos de CMD aquí en el menú contextual. -
Introduzca el siguiente comando para codificar el ID de cliente y el secreto de cliente:
certutil -encode appCreds.txt appbase64Creds.txt -
En el Bloc de notas, abra
C:\temp\appbase64Creds.txt, copie su contenido y, a continuación, cierre el archivo.Nota
Por motivos de seguridad, suprima los archivosappCreds.txtyappbase64Creds.txtuna vez que haya terminado.
Mac y Linux
-
Inicie su utilidad de notas preferida (por ejemplo, Mac Notes, Gedit Linux o Vi) y, a continuación, pegue el ID de cliente y el secreto de cliente en la utilidad de notas.
Coloque el ID y el secreto de cliente en la misma línea e inserte dos puntos entre ellos:
clientid:clientsecret.Notasentencia.
Asegúrese de que no haya espacios en clientid:clientsecret.-
Copie la línea
clientid:clientsecret. -
Inicie un terminal e introduzca el siguiente comando, sustituyendo
clientid:clientsecretpor el valor que ha copiado en el portapapeles.echo -n "clientid:clientsecret" | base64 -w 0Nota
Para Linux, agregue-w 0al comando para eliminar saltos de línea. -
Copie el valor devuelto.Nota
Si el valor que se devuelve se divide en más de una línea, vuelva al editor de texto y asegúrese de que todos los resultados están en una sola línea sin ajuste de texto.
Paso 3: Obtener un token de acceso
El siguiente paso de este proceso es solicitar el token de acceso.
-
Inicie un símbolo del sistema.
-
Introduzca el comando cURL a continuación, sustituyendo el texto entre corchetes ( < > ) por los valores adecuados:
curl -i -H "Authorization: Basic <base64encoded clientid:secret>" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=client_credentials&scope=urn:opc:idm:__myscopes__"Nota
Si utiliza un sistema operativo UNIX, puede agregar| awk -F"\"" '{print $4}'al final del comando cURL para analizar solo el token de portador. Solo recuerde que la caducidad predeterminada del token es de 3600 segundos desde el momento de la solicitud.Nota
Opcionalmente, ejecute el siguiente comando de cURL para que se pueda acceder al valor del token de acceso a través de una variable de UNIX denominadaAccessTokenValueen el entorno:
A continuación, puede ejecutar el comandoexport AccessTokenValue=`curl -i -H "Authorization: Basic <base64encoded clientid:secret>" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=client_credentials&scope=urn:opc:idm:__myscopes__" | awk -F"\"" '{print $4}' | tail -n +16`echo $AccessTokenValuepara obtener el valor del token de acceso.Texto en paréntesis Valor base64encoded clientid:secret Sustituya por las credenciales codificadas que ha generado en la sección Base64 Codifique el ID de cliente y el secreto de cliente. Asegúrese de que no haya espacios en las credenciales clientid:clientsecret. IDCS_Service_Instance Sustituya por la URL del dominio de identidad (por ejemplo, https://<domainURL>/).Nota
Los clientes de dominio de identidad utilizan el ámbitourn:opc:idm:__myscopes__del comando como etiqueta para solicitar tokens de acceso desde el servidor de autorización OAuth. Se devuelven tokens de acceso que contienen todos los ámbitos de dominios de identidad aplicables en función de los privilegios representados por los roles de administrador de dominios de identidad otorgados al cliente solicitante y al usuario que está especificando la solicitud del cliente (si existe). Este ámbito no se otorga directamente a ningún rol de administrador de dominios de identidad. -
Copie el valor
access_tokende la respuesta. Asegúrese de copiar solo el token real, que es el valoraccess_tokenentre las comillas:Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer", "expires_in":3600Nota
La respuesta incluye el parámetroexpires_in: 3600. Esto significa que su token ya no es válido después de una hora desde el momento en que lo genera. Después de una hora, debe refrescar el token u obtener un nuevo token de acceso. Para refrescar el token, introduzca el comando cURL a continuación y sustituya el texto entre corchetes ( < > ) por los valores adecuados:curl -i -H "Authorization: Basic <base64 encoded client ID and secret>" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=refresh_token&refresh_token=<token_value>"
Paso 4: Realizar una solicitud REST para el entorno
Después de obtener el token de acceso OAuth 2.0, puede utilizar el token en un comando de cURL para enviar una solicitud de REST a la API de REST de los dominios de identidad. El siguiente comando devuelve una lista de usuarios en un dominio de identidad.
curl -X GET
-H "Content-Type:application/scim+json"
-H "Authorization: Bearer <access_token>"
https://<domainURL>/admin/v1/Users
| Elemento | Valor |
|---|---|
| Método | -X OBTENER |
| Encabezado de tipo de contenido | -H "Tipo de contenido: aplicación/scim-json" |
| Cabecera de autorización | -H "Autorización: Portador <access_token>" |
| Protocolo HTTP | HTTP o HTTPS (se recomienda HTTP) |
| Dominio de identidad | URL del dominio de identidad (por ejemplo, https://<domainURL>). |
| Punto final de REST de dominios de identidad | /admin/v1/Users |
Ejemplo de salida JSON de la API de REST de dominios de identidad
En el paso anterior, la solicitud de REST enviada mediante cURL devolvió una respuesta en formato JSON. JSON es un estándar abierto que se puede formatear o analizar según sus necesidades, como la obtención de atributos específicos requeridos por su aplicación.
{
"schemas": [
"urn:scim:api:messages:2.0:ListResponse"
],
"totalResults": 1,
"Resources": [
{
"displayName": "admin opc",
"name": {
"givenName": "admin",
"formatted": "admin opc",
"familyName": "opc"
},
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User": {
"locked": {
"on": false
}
},
"userName": "admin@example.com",
"id": "d252a54d83c344eb8f59f7053a0562ce",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
"isFederatedUser": false
},
"active": true,
"nickName": "TAS_TENANT_ADMIN_USER",
"emails": [
{
"verified": false,
"value": "admin@example.com",
"type": "work",
"primary": true
},
{
"verified": false,
"value": "admin@example.com",
"primary": false,
"type": "recovery"
}
],
"schemas": [
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User",
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"meta": {
"resourceType": "User",
"created": "2022-07-22T18:11:08Z",
"lastModified": "2022-07-25T21:19:28Z",
"location": "https://<domainURL>admin/v1/Users/d252a54d83c344eb8f59f7053a0562ce"
},
"idcsLastModifiedBy": {
"value": "idcssso",
"$ref": "https://<domainURL>admin/v1/Apps/idcssso",
"type": "App",
"display": "idcssso"
}
}
],
"startIndex": 1,
"itemsPerPage": 50
}