IBM Cloud Docs
Tecnologías

Tecnologías

¿Está confundido sobre las diferencias entre la autorización y la autenticación? No es el único. Consulte la información siguiente para obtener información sobre terminología específica, los procesos y las tecnologías que se utilizan al trabajar con IBM Cloud® App ID.

¿Quiere saber más sobre algunos conceptos básicos de la autorización y autenticación? No busque más. En el siguiente vídeo puede aprender sobre OAuth 2.0, tipos de otorgamiento, OIDC, etc.

OAuth 2

OAuth 2.0 es un protocolo estándar abierto que se utiliza para autorizar aplicaciones.

Open ID Connect (OIDC)

OIDC es una capa de autenticación que funciona con OAuth 2. Cuando utiliza OIDC y App ID juntos, las credenciales de la aplicación ayudan a configurar los puntos finales de OAuth. Si utiliza el SDK, los URL de punto final se crean automáticamente. Sin embargo, también puede crear los URL por su cuenta con sus credenciales de servicio. El URL tiene el siguiente formato: punto final de servicio de App ID + "/oauth/v4" + /tenantID.

Ejemplo:

{
  "clientId": "7eba72ef-b913-47b0-b3b6-54358bb69035",
  "tenantId": "8f5aa500-357e-443a-aab6-bf878f852b5a",
  "secret": "OWEzZGM4M2UtZjhlYS00MDI2LTkwNGItNDJmYzViMmU2YzIz",
  "name": "testing",
  "oAuthServerUrl": "https://us-south.appid.cloud.ibm.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a",
  "profilesUrl": "https://us-south.appid.cloud.ibm.com",
  "discoveryEndpoint": "https://us-south.appid.ibm.cloud.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a/.well-known/openid-configuration"
}

En este ejemplo, el URL sería https://us-south.appid.cloud.ibm.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a. A continuación, añadiría el punto final al que desea realizar una solicitud. Consulte la tabla siguiente para ver algunos puntos finales de ejemplo.

Ejemplos de puntos finales
Punto final Formato
Autorización <oauthServerUrl>/authorization
Señal <oauthServerUrl>/token
Información de usuario <oauthServerUrl>/userinfo
JWKS <oauthServerUrl>/publickeys

Cuando utiliza el SDK, los URL de punto final se crean automáticamente.

Señales

El servicio utiliza tres tipos de señales distintas. Las señales se definen en Proveedores de identidad > Gestionar del panel de control de App ID. Para obtener más información sobre las señales y cómo se utilizan en App ID, consulte Gestión de señales.

  • Señales de acceso: represente la autorización y habilite la comunicación con recursos de fondo protegidos. Los recursos están protegidos por filtros de autorización definidos por App ID.

  • Señales de identidad: representan la autenticación y contienen información sobre el usuario.

  • Señales de renovación: se pueden utilizar para obtener una nueva señal de acceso sin volver a autenticar al usuario. Mediante el uso de señales para renovación, los usuarios pueden permitir que la aplicación recuerde sus datos, lo que significa que pueden mantener la sesión iniciada.

Cabeceras de autorización

App ID cumple con la especificación Bearer token y utiliza una combinación de tokens de acceso e identidad que se envían como cabecera HTTP Authorization. La cabecera de autorización tiene tres partes distintas separadas con un espacio en blanco. Las señales están codificadas en base64. La señal de identidad es opcional.

Ejemplo:

Authorization=Bearer <accessToken> [<idToken>]

Estrategia de API

La estrategia de API espera que las solicitudes contengan una cabecera de autorización con una señal de acceso válida. La solicitud también puede incluir una señal de identidad, pero no es obligatorio. Si una señal no es válida o ha caducado, la estrategia de API devuelve un error HTTP 401 que contiene la siguiente cabecera HTTP:

Www-Authenticate=Bearer scope="<scope>" error="<error>"

Si la solicitud devuelve una señal válida, el control se pasa al siguiente middleware y la propiedad appIdAuthorizationContext se inyecta en el objeto de solicitud. Esta propiedad contiene señales de acceso e identidad originales, e información de carga útil descodificada como objetos JSON simples.

Estrategia de app web

Cuando la estrategia de app web detecta intentos no autorizados de acceso a un recurso protegido, automáticamente redirige el navegador de un usuario a la página de autenticación, que puede estar proporcionada por App ID. Tras la correcta autenticación, el usuario vuelve al URL de devolución de llamada de la app web. La estrategia de app web obtiene las señales de acceso e identidad y las almacena en una sesión HTTP bajo WebAppStrategy.AUTH_CONTEXT. Depende del usuario decidir si desea almacenar las señales de acceso e identidad en la base de datos de la app.

URI de redirección

App ID utiliza una lista de URI completos y aprobados para redirigir a los usuarios después de una interacción con la app. Por ejemplo, si el usuario inicia sesión correctamente, App ID redirige al usuario a la página de inicio de la app o a otra página que especifique. El formato del URI puede cambiar en función de la aplicación. Consulte Adición de URI de redirección para obtener más información.

Conjunto de claves web JSON (JWKS)

Un JWKS representa un conjunto de claves criptográficas. App ID utiliza un JWKS para verificar la autenticidad de las señales generadas por el servicio. Al utilizar el ID de clave para verificar la firma, podemos garantizar que la señal ha sido emitida por una fuente de confianza - App ID. También podemos garantizar que la información dentro de la señal nunca ha sido modificada.