Validación de señales

La validación de señales es una parte importante del desarrollo de apps modernas. Al validar las señales, puede proteger la aplicación o las API de usuarios no autorizados. IBM Cloud® App ID utiliza las señales de acceso y de identidad para asegurarse de que un usuario o una aplicación se autentica antes de que se les otorgue acceso. Si está utilizando uno de los SDK proporcionados por App ID, la obtención y la validación de señales se realizarán en su nombre.

Para obtener más información sobre cómo se utilizan las señales en App ID, consulte Comprensión de las señales.

Las señales se utilizan para verificar que una persona es quien dice ser. Confirman los permisos de acceso que el usuario puede tener durante un período de tiempo especificado. Cuando un usuario inicia sesión en la aplicación y se emite una señal, la aplicación debe validar el usuario antes de que se le dé acceso.

¿Qué ocurre si estoy trabajando en un idioma para el que App ID no dispone de un SDK?

Dispone de tres opciones:

  • Trabajar con las API de App ID
  • Implementar su propia lógica de validación
  • Utilizar un SDK de código abierto compatible con OpenID Connect

Utilización de la API App ID

Al utilizar la introspección, puede utilizar App ID para validar las señales.

  1. Envíe una solicitud POST al punto final de API de /introspect para validar la señal. La solicitud debe proporcionar la señal y una cabecera de autorización básica que contenga el ID de cliente y el secreto.

    Solicitud de ejemplo:

    POST /oauth/v4/<tenantID>/introspect HTTP/1.1
Host: us-south.appid.cloud.ibm.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic jdFlUaGlZUzAwTW0Tjk15TmpFMw==
Cache-Control: no-cache

token=XXXXX.YYYYY.ZZZZZ

  2. El servidor comprueba la caducidad y la firma de la señal y devuelve un objeto JSON que indica si la señal está activa o inactiva.

    Respuesta de ejemplo:

    {
"active": true
}

Validación manual de señales

Puede validar las señales de forma local analizando la señal, verificando la firma de la señal y validando las reclamaciones que se almacenan en la señal.

  1. Analice las señales. El token web JSON(JWT) es una forma estándar de transmitir información de forma segura. Consta de tres partes principales: cabecera, carga útil y firma. Están codificados en base64URL y separados por un punto (.). Puede utilizar cualquier decodificador base64URL disponible para analizar la señal. Alternativamente, puede utilizar cualquiera de las bibliotecas que aparecen en la lista para analizar el token.

    Señal codificada de ejemplo:

    eyJhbGciOiJSUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJhMmszIn0
.eyJpc3MiOiJhcHBpZC1vYXV0aCIsImF1ZCI6ImFiYzEyMyIsImV4cCI6MTU2NDU2Nn0
.IycnAGUmMHzpTWbe-qaRsx0B4Zi-SVav710Fb_8CTCQvLrHX9d42WuCZ5bW
d-ikgEsf6waQxeBfhfwYxwHN87LZupApagVMZtylVAnXhG1pHu_32wbZsPvg6QjzNO
j6ys2Lfl3qfb5Qrp9u4IsZltKPEN8HdfeOcKXxpw6UqP-8

    Señal decodificada de ejemplo:

    {
"alg": "RS256",
"typ": "JOSE",
"kid": "a2k3",
"iss": "https://us-south.appid.cloud.ibm.com/oauth/v4/39a37f57-a227-4bfe-a044-93b6e6050a61",
"aud": "abc123",
"exp": 1564566
}

  2. Realice una llamada al punto final /publickeys para recuperar las claves públicas. Las claves públicas devueltas se formatean como claves web JSON(JWK).

    Solicitud de ejemplo:

    GET /oauth/v4/<tenantID>/publickeys HTTP/1.1
Host: us-south.appid.cloud.ibm.com
Cache-Control: no-cache

  3. Almacene las claves en la memoria caché de la app para su uso futuro. El almacenamiento de claves acelera el proceso e impide el retraso de la red si se realiza otra llamada.

  4. Importe los parámetros de clave pública.

    Respuesta de ejemplo:

    {
"keys": [
   {
      "kty": "RSA",
      "use": "sig",
      "n": "AsdaE",
      "e": "SDAasw",
      "kid": "ad123dCAz"
   }
]
}
    Parámetros de clave pública
    Parámetro Descripción
    kty Define el algoritmo que se utiliza.
    use Define la finalidad de la clave.
    kid Define el ID exclusivo de la clave.
    Otros Es posible que haya otros parámetros que sean específicos de su algoritmo que también deban importarse.

  5. Verifique la firma de la señal. La cabecera de la señal contiene el algoritmo que se ha utilizado para firmar la señal y el ID de clave o reclamación kid de la clave pública coincidente. Puesto que las claves públicas no cambian con frecuencia, puede almacenar en memoria caché claves públicas en la app y renovarlas ocasionalmente. Si a la clave almacenada en caché le falta la reclamación kid, puede validar las señales localmente.

    1. Haga que la aplicación verifique que el contenido de la cabecera de señal de entrada coincida con los parámetros de la clave pública.
    2. Compruebe de forma específica que se han utilizado los mismos algoritmos y que la memoria caché de la clave pública contiene una clave con el ID de clave relevante.
    3. Asegúrese de que el valor de hash es el mismo que el de la firma del formulario PEM de la clave pública. El valor hash se puede obtener mediante el hashing y la combinación de la cabecera de la carga útil de la señal. Puesto que el proceso puede ser completo para implementarlo de forma manual, puede resultar útil utilizar una de las bibliotecas listadas para validar la firma.

  6. Valide las reclamaciones que se almacenan en las señales. Para verificar comprobaciones futuras, puede utilizar esta lista.

    Declaraciones que deben validarse
    Reclamación Descripción
    iss El emisor debe ser el mismo que el del servidor OAuth de App ID.
    exp La hora actual debe ser inferior a la hora de caducidad.
    aud El público debe contener el ID de cliente de la app.
    tenant El arrendatario debe contener el ID de arrendatario de la app.
    scope El ámbito de permisos que se otorga al usuario. Es específico de la señal de acceso.