Escenarios habituales - AWS Identity and Access Management
Amazon Cognito para aplicaciones móvilesFederación de OIDC para aplicaciones móviles

Escenarios habituales

nota

Se recomienda exigir a los usuarios humanos que utilicen credenciales temporales cuando accedan a AWS. ¿Ha considerado la posibilidad de usar AWS IAM Identity Center? Puede usar IAM Identity Center para administrar de forma centralizada el acceso a múltiples Cuentas de AWS y proporcionar a los usuarios un acceso protegido por MFA y de inicio de sesión único a todas sus cuentas asignadas desde un solo lugar. Con IAM Identity Center, puede crear y administrar identidades de usuario en IAM Identity Center o conectarse fácilmente a su proveedor de identidades existente compatible con SAML 2.0. Para obtener más información, consulte ¿Qué es el Centro de identidades de IAM? en la Guía del usuario de AWS IAM Identity Center.

Puede utilizar un proveedor de identidades (IdP) externo para gestionar las identidades de los usuarios externos a AWS y el IdP externo. Un IdP externo puede proporcionar información de identidad de AWS mediante OpenID Connect (OIDC) o el lenguaje de marcado de aserciones de seguridad (SAML). El OIDC se suele utilizar cuando una aplicación que no se ejecuta en AWS necesita acceder a los recursos AWS.

Si desea configurar la federación con un IdP externo, debe crear un proveedor de identidades de IAM para informar a AWS sobre el IdP externo y su configuración. Esto establece una relación de confianza entre su Cuenta de AWS y el IdP externo. En los siguientes temas, se proporcionan escenarios comunes para usar proveedores de identidades de IAM.

Amazon Cognito para aplicaciones móviles

La mejor forma de utilizar las federaciones de OIDC es emplear Amazon Cognito. Por ejemplo, Adele, la desarrolladora, está creando un juego para un dispositivo móvil donde los datos de usuario, como perfiles y puntuaciones, se almacenan en Amazon S3 y Amazon DynamoDB. Adele también podría almacenar estos datos localmente en el dispositivo y utilizar Amazon Cognito para mantenerlos sincronizados en todos los dispositivos. Ella sabe que por razones de seguridad y mantenimiento, las credenciales de seguridad de AWS a largo plazo no deben distribuirse con el juego. También sabe que el juego podría tener un gran número de usuarios. Por todo ello, no quiere crear nuevas identidades de usuario en IAM para cada jugador. En cambio, diseña el juego de manera que los usuarios puedan iniciar sesión con una identidad que ya han establecido con un proveedor de identidad (IdP) externo bien conocido, como Login with Amazon, Facebook, Google o cualquier IdP compatible con OpenID Connect (OIDC). Su juego puede aprovechar el mecanismo de autenticación de uno de estos proveedores para validar la identidad del usuario.

Para permitir que la aplicación móvil pueda acceder a sus recursos de AWS, Adele registra primero un ID de desarrollador con el proveedor de identidad elegido. También configura la aplicación con cada uno de estos proveedores. En su Cuenta de AWS que contiene el bucket de Amazon S3 y la tabla de DynamoDB para el juego, Adele utiliza Amazon Cognito para crear roles de IAM que definen de forma precisa los permisos que necesita el juego. Si está utilizando un IdP de OIDC, también crea una entidad de proveedor de identidades de OIDC de IAM para establecer una relación de confianza entre un grupo de identidades de Amazon Cognito de la Cuenta de AWS y el IdP.

En el código de aplicación, Adele llama a la interfaz de inicio de sesión para el proveedor de identidad que ha configurado anteriormente. El proveedor de identidad gestiona todos los detalles que permiten iniciar sesión al usuario y la aplicación obtiene un token de acceso OAuth o un token de ID de OIDC del proveedor. La aplicación de Adele puede intercambiar esta información de autenticación por un conjunto de credenciales de seguridad temporales que constan de un ID de clave de acceso de AWS, una clave de acceso secreta y un token de sesión. A continuación, la aplicación puede utilizar estas credenciales para obtener acceso a los servicios web que ofrece AWS. La aplicación está limitada por los permisos que están definidos en el rol que asume.

La imagen siguiente muestra un flujo simplificado de su funcionamiento, utilizando Login with Amazon como proveedor de identidad. En el paso 2, la aplicación también puede utilizar Facebook, Google o cualquier IdP compatible con OIDC, pero no se muestra aquí.

Ejemplo de flujo de trabajo utilizando Amazon Cognito con usuarios federados para una aplicación móvil

  1. Un cliente inicia la aplicación en un dispositivo móvil. La aplicación solicita al usuario que inicie la sesión.

  2. La aplicación utiliza los recursos de Login with Amazon para aceptar las credenciales del usuario.

  3. La aplicación utiliza operaciones GetId y GetCredentialsForIdentity de la API de Amazon Cognito para intercambiar el token de ID de Login with Amazon por un token de Amazon Cognito. Amazon Cognito, que se ha configurado para confiar en su proyecto de Login with Amazon, genera un token que intercambia por credenciales de sesión temporales con AWS STS.

  4. La aplicación recibe credenciales de seguridad temporales de Amazon Cognito. La aplicación también puede usar el flujo de trabajo básico (clásico) de Amazon Cognito para recuperar tokens de AWS STS con AssumeRoleWithWebIdentity. Para obtener más información acerca del modo en que ayuda a la autenticación de usuarios, consulte Identity pools (federated identities) authentication flow (Flujo de autenticación de grupo de identidades [federadas]) en la Amazon Cognito Developer Guide (Guía para desarrolladores de Amazon Cognito).

  5. La aplicación puede utilizar las credenciales de seguridad temporales para acceder a los recursos de AWS que necesita la aplicación para funcionar. El rol asociado con las credenciales de seguridad temporales y sus políticas asignadas determina a qué se puede acceder.

Utilice el siguiente proceso para configurar la aplicación para utilizar Amazon Cognito para autenticar los usuarios y otorgar a la aplicación acceso a los recursos de AWS. Para conocer los pasos específicos en este escenario, consulte la documentación de Amazon Cognito.

  1. (Opcional) Regístrese como desarrollador en Login with Amazon, Facebook, Google o cualquier otro IdP compatible con OpenID Connect (OIDC) y configure una o varias aplicaciones con el proveedor. Este paso es opcional, ya que Amazon Cognito también admite acceso sin autenticar (como invitado) para los usuarios.

  2. Diríjase a Amazon Cognito de AWS Management Console. Utilice el asistente de Amazon Cognito para crear un grupo de identidades, que es un contenedor que Amazon Cognito utiliza para mantener las identidades de los usuarios finales organizados para las aplicaciones. Puede compartir grupos de identidades entre aplicaciones. Al configurar un grupo de identidades, Amazon Cognito crea uno o dos roles de IAM (uno para las identidades autenticadas y otro para las identidades "invitadas" sin autenticar) que definen los permisos para los usuarios de Amazon Cognito.

  3. Integre AWS Amplify con su aplicación e importe los archivos necesarios para usar Amazon Cognito.

  4. Cree una instancia del proveedor de credenciales de Amazon Cognito, transmitiendo el ID de grupo de identidades, el número de Cuenta de AWS y el nombre de recurso de Amazon (ARN) de los roles que asocia con el grupo de identidades. El asistente de Amazon Cognito en la AWS Management Console proporciona código de muestra para ayudarle a comenzar.

  5. Cuando la aplicación accede a un recurso de AWS, transfiere la instancia de credenciales de proveedor al objeto de cliente, que a su vez transmite las credenciales de seguridad temporales al cliente. Los permisos de las credenciales se basan en el rol o roles que ha definido previamente.

Para más información, consulte los siguientes temas:

  • Sign in (Android) (Iniciar sesión [Android]) en la documentación de AWS Amplify Framework.

  • Sign in (iOS) (Iniciar sesión [iOS]) en la documentación de AWS Amplify Framework.

Federación de OIDC para aplicaciones móviles

Para obtener los mejores resultados, utilice Amazon Cognito como su agente de identidades para casi todos los casos de federación de OIDC. Amazon Cognito es fácil de utilizar y ofrece capacidades adicionales, tales como acceso anónimo (no autenticado) y sincronización de datos del usuario entre varios dispositivos y proveedores. Sin embargo, si ya ha creado una aplicación que utiliza federación de OIDC llamando manualmente a la API AssumeRoleWithWebIdentity, puede seguir utilizándola y sus aplicaciones seguirán funcionando correctamente.

El esquema general del proceso de uso de una federación de OIDC sin Amazon Cognito es el siguiente:

  1. Inscríbase como desarrollador con el proveedor de identidad (IdP) externo y configure su aplicación con él, que le proporcionará un ID único para su aplicación. (Cada IdP utiliza una terminología diferente para este proceso. En este esquema se utiliza el término configurar para el proceso de identificación de su aplicación con el IdP). Cada proveedor de identidad (IdP) le ofrece una ID de aplicación exclusivo para dicho IdP, de modo que si configura la misma aplicación con varios proveedores de identidad (IdP), la aplicación tendrá varios ID de aplicación. Puede configurar varias aplicaciones en un mismo proveedor.

    Los siguientes enlaces externos proporcionan información sobre el uso de algunos de los proveedores de identidad (IdP) habituales:

    importante

    Si utiliza un proveedor de identidades OIDC de Google, Facebook o Amazon Cognito, no cree un proveedor de identidad de IAM independiente en el AWS Management Console. AWS tiene estos proveedores de identidad OIDC incorporados y disponibles para su uso. Omita el siguiente paso y vaya directamente a crear nuevos roles con su proveedor de identidades.

  2. Si utiliza un proveedor de identidad (IdP) distinto de Google, Facebook o Amazon Cognito compatible con OIDC, cree una entidad de proveedor de identidades de IAM para dicho proveedor.

  3. En IAM, cree uno o varios roles. Para cada rol, defina quién puede asumir el rol (la política de confianza) y los permisos que los usuarios de la aplicación tienen (la política de permisos). Por lo general, debe crear un rol para cada proveedor de identidad (IdP) que una aplicación admite. Por ejemplo, puede crear un rol que asume una aplicación si el usuario inicia sesión mediante Login with Amazon, un segundo rol para la misma aplicación si el usuario inicia sesión en Facebook y un tercer rol para la aplicación si el usuario inicia sesión a través de Google. En el caso de la relación de confianza, especifique el proveedor de identidad (IdP) (como Amazon.com) como Principal (la entidad de confianza) e incluya un elemento Condition que coincida con el ID de la aplicación asignado al proveedor de identidad (IdP). En Crear un rol para un proveedor de identidad de terceros (federación) podrá encontrar ejemplos de roles para distintos proveedores.

  4. En su aplicación, autentique los usuarios con el proveedor de identidad (IdP). Los detalles de cómo hacerlo varían en función del proveedor de identidad que utilice (Login with Amazon, Facebook o Google) y de la plataforma de la aplicación. Por ejemplo, el método de autenticación de una aplicación Android puede diferir del método de una aplicación iOS o una aplicación web basada en JavaScript.

    Por lo general, si el usuario aún no ha iniciado sesión, el proveedor de identidad (IdP) se encarga de mostrar una página de inicio de sesión. Una vez que el proveedor de identidad (IdP) autentica al usuario, el IdP devuelve un token de autenticación con información sobre el usuario a su aplicación. La información que se incluye depende de lo que el proveedor de identidad (IdP) expone y de la información que el usuario está dispuesto a compartir. Puede utilizar esta información en su aplicación.

  5. En su aplicación, realice una llamada sin firma a la acción AssumeRoleWithWebIdentity para solicitar credenciales de seguridad temporales. En la solicitud, transmita el token de autenticación del proveedor de identidades (IdP) y especifique el Nombre de recurso de Amazon (ARN) para el rol de IAM que ha creado para dicho proveedor. AWS verifica que el token es de confianza y válido y, en tal caso, devuelve las credenciales de seguridad temporales a su aplicación que tienen los permisos para el rol que indica en la solicitud. La respuesta también incluye los metadatos sobre el usuario del proveedor de identidad (IdP), tales como el ID de usuario único que el proveedor de identidad (IdP) asocia al usuario.

  6. Al utilizar las credenciales de seguridad temporales de la respuesta de AssumeRoleWithWebIdentity, la aplicación envía solicitudes firmadas a las operaciones de la API de AWS. La información del ID de usuario del IdP puede distinguir a los usuarios de la aplicación. Por ejemplo, puede colocar objetos en las carpetas de Amazon S3 que incluyan el ID de usuario como prefijos o sufijos. Esto le permite crear políticas de control de acceso que bloqueen la carpeta para que solo el usuario con dicho ID pueda tener acceso a ella. Para obtener más información, consulte Entidades principales de sesión de usuario federado de AWS STS.

  7. Su aplicación debe almacenar en caché las credenciales de seguridad temporales para que no tenga que obtener unas nuevas cada vez que la aplicación tenga que realizar una solicitud a AWS. De forma predeterminada, las credenciales son válidas durante una hora. Cuando las credenciales caduquen (o antes), realice otra llamada a AssumeRoleWithWebIdentity para obtener un nuevo conjunto de credenciales de seguridad temporales. En función del proveedor de identidad (IdP) y el modo en que administra sus tokens, es posible que tenga que actualizar el token del proveedor de identidad (IdP) antes de realizar una nueva llamada a AssumeRoleWithWebIdentity, ya que los tokens del proveedor de identidad (IdP) también suelen caducar después de un tiempo establecido. Si utiliza el SDK for iOS de AWS o el SDK for Android de AWS, puede utilizar la acción AmazonSTSCredentialsProvider, que administra las credenciales temporales de IAM, incluida su actualización según sea necesario.