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 principales estándar de SCIM 2.0 y extensiones de esquema de Oracle para gestionar mediante programación usuarios, grupos, aplicaciones y funciones de identidad, como tareas administrativas y de gestión de contraseñas. Para realizar llamadas a la 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 OAuth 2.0 específicos al trabajar con un dominio de identidad. En la tabla siguiente 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ásico 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 concatenados mediante dos puntos como separador, por ejemplo, clientID:clientSecret. |
Identificador de Cliente |
<client_id> |
Es necesario. Una "clave de API" única que se genera al registrar la aplicación en la consola del dominio de identidad. |
Cliente |
<client_secret> |
Es 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 |
Es necesario. Significa que la API de REST que se llama es propiedad de la aplicación cliente. |
Ámbito (necesario) |
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 implantar 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 qué 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, creación y supresiones de usuarios. Sin embargo, si tuviera que hacer otras cosas, 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 haga clic en Identidad y seguridad. En Identidad, haga clic en 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.
- Haga clic en Agregar aplicación.
- En el cuadro de diálogo Agregar aplicación, seleccione Aplicación confidencial y, a continuación, haga clic en Iniciar flujo de trabajo.
- En la página Agregar detalles de aplicación, introduzca un nombre de aplicación y una descripción y, a continuación, haga clic en Siguiente.
- En la página Configure OAuth, en Configuración del cliente, seleccione Configure 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 aplicaciones y, a continuación, haga clic en Agregar roles.
- En el panel Agregar roles de aplicación, seleccione Administrador de dominio de identidad y, a continuación, haga clic en Agregar.
- Haga clic en Siguiente y, a continuación, en Terminar.
- En la página de detalles 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.
- Una vez creada la aplicación, haga clic en Activar.
Paso 2: Base64 Codifique el ID de cliente y el secreto de cliente
Antes de la codificación base64, la URL codifica individualmente 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 codifique primero la URL. Sin embargo, como mejor práctica, lo recomendamos encarecidamente.
Windows
-
Inicie el Bloc de notas y, a continuación, pegue el ID de cliente y el secreto de cliente en el Bloc de notas.
-
Coloque el ID de cliente y el secreto de cliente en la misma línea e inserte dos puntos entre ellos:
clientid:clientsecret
Nota
Asegúrese de que no haya espacios en el atributo clientid:clientsecret. -
Guarde el archivo en
C:\temp
y asígnele el nombreappCreds.txt.
-
En el Explorador de Windows, haga clic con el botón derecho en
C:\temp
y, 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.txt
yappbase64Creds.txt
después de terminar.
Mac y Linux
-
Inicie la utilidad de nota preferida (por ejemplo, Notas de Mac, Gedit Linux o Vi) y, a continuación, pegue el ID de cliente y el secreto de cliente en la utilidad de nota.
Coloque el ID de cliente 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:clientsecret
por el valor que copió en el portapapeles.echo -n "clientid:clientsecret" | base64 -w 0
Nota
Para Linux, agregue-w 0
al comando para eliminar saltos de línea. -
Copie el valor que se devuelve.Nota
Si el valor que se devuelve está dividido 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 en este proceso es solicitar el token de acceso.
-
Inicie un símbolo del sistema.
-
Escriba el siguiente comando de cURL, 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 Bearer. Solo recuerde que la caducidad predeterminada del token es de 3600 segundos desde el momento de la solicitud.Nota
Opcionalmente, ejecute el siguiente comando cURL para que se pueda acceder al valor del token de acceso mediante una variable UNIX denominadaAccessTokenValue
en 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 $AccessTokenValue
para obtener el valor del token de acceso.Texto entre corchetes Valor base64encoded ID de clien: secreto Reemplace por las credenciales codificadas que generó 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 Reemplazar por la URL del dominio de identidad (por ejemplo, https://<domainURL>/).
)Nota
El ámbitourn:opc:idm:__myscopes__
del comando lo utilizan como etiqueta los clientes del dominio de identidad que solicitan 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 especificado por la solicitud del cliente (si está presente). Este ámbito no se otorga directamente a ningún rol de administrador de dominios de identidad. -
Copie el valor
access_token
de la respuesta. Asegúrese de copiar solo el token real, que es el valoraccess_token
entre comillas:Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer", "expires_in":3600
Nota
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.
Paso 4: Realizar una solicitud REST al entorno
Después de obtener el token de acceso OAuth 2.0, puede utilizar el token en un comando cURL para enviar una solicitud 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 |
Cabecera 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 | La URL del dominio de identidad (por ejemplo, https://<domainURL>). ) |
Punto final 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 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 obtener 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
}