Azure AD B2C: protocolos de autenticación

Azure Active Directory B2C (Azure AD B2C) proporciona identidad como servicio para las aplicaciones, ya que admite dos protocolos estándar del sector: OpenID Connect y OAuth 2.0. El servicio es compatible con los estándares, pero las dos implementaciones de estos protocolos pueden tener diferencias sutiles.

La información de esta guía es útil si escribe el código enviando y controlando directamente las solicitudes HTTP, en lugar de usar una biblioteca de código abierto. Se recomienda leer esta página antes de profundizar en los detalles de cada protocolo específico. Pero si ya está familiarizado con Azure AD B2C, puede ir directamente a las guías de referencia del protocolo.

Conceptos básicos

Todas las aplicaciones que usan Azure AD B2C deben registrarse en el directorio B2C de Azure Portal. El proceso de registro de aplicaciones recopila y asigna algunos valores a la aplicación:

• Un identificador de aplicación que identifica de forma única la aplicación.

• Un URI de redirección o un identificador de paquete que se puede usar para devolver las respuestas a su aplicación.

• Algunos otros valores específicos del escenario. Para obtener más información, aprenda a registrar la aplicación.

Después de registrar la aplicación, se comunica con Azure AD B2C mediante el envío de solicitudes al punto de conexión:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

Si usa un dominio personalizado, reemplace por {tenant}.b2clogin.com el dominio personalizado, como contoso.com, en los puntos de conexión.

En casi todos los flujos de OAuth y OpenID Connect, cuatro partes participan en el intercambio:

• El servidor de autorización es el punto de conexión de Azure AD B2C. Controla de forma segura todo lo relacionado con la información y el acceso de los usuarios. También controla las relaciones de confianza entre las partes de un flujo. Es responsable de comprobar la identidad del usuario, conceder y revocar el acceso a los recursos y emitir tokens. También se conoce como proveedor de identidades.

• Normalmente, el propietario del recurso es el usuario final. Es la entidad propietaria de los datos y tiene la capacidad de permitir que terceros accedan a esos datos o recursos.

• El cliente de OAuth es tu aplicación. Se identifica mediante su identificador de aplicación. Normalmente es la entidad con la que interactúan los usuarios finales. También solicita tokens desde el servidor de autorización. El propietario del recurso debe conceder al cliente permiso para acceder al recurso.

• El servidor de recursos es donde reside el recurso o los datos. Confía en el servidor de autorización para autenticar y autorizar de forma segura el cliente de OAuth. También usa tokens de acceso de tipo 'bearer' para asegurarse de poder conceder acceso a un recurso.

Directivas y flujos de usuario

Azure AD B2C amplía los protocolos estándar de OAuth 2.0 y OpenID Connect mediante la introducción de directivas. Esto permite que Azure AD B2C realice mucho más que la autenticación y autorización simples.

Para ayudarle a configurar las tareas de identidad más comunes, el portal de Azure AD B2C incluye directivas predefinidas y configurables denominadas flujos de usuario. Los flujos de usuario describen completamente las experiencias de identidad del consumidor, incluido el registro, el inicio de sesión y la edición de perfiles. Los flujos de usuario se pueden definir en una interfaz de usuario administrativa. Se pueden ejecutar mediante un parámetro de consulta especial en las solicitudes de autenticación HTTP.

Las directivas y los flujos de usuario no son características estándar de OAuth 2.0 y OpenID Connect, por lo que debe dedicar tiempo a comprenderlos. Para más información, consulte la guía de referencia del flujo de usuario de Azure AD B2C.

Fichas

La implementación de Azure AD B2C de OAuth 2.0 y OpenID Connect hace un uso amplio de tokens de portador, incluidos los tokens de portador que se representan como tokens web JSON (JWT). Un token de portador es un token de seguridad ligero que concede al "portador" acceso a un recurso protegido.

El portador es cualquier entidad que pueda presentar el token. Azure AD B2C debe autenticar primero a una entidad para poder recibir un token de portador. Pero si no se realizan los pasos necesarios para proteger el token en la transmisión y el almacenamiento, se puede interceptar y usar por parte no deseada.

Algunos tokens de seguridad tienen mecanismos integrados que impiden que las partes no autorizadas las usen, pero los tokens de portador no tienen este mecanismo. Deben transportarse en un canal seguro, como una seguridad de la capa de transporte (HTTPS).

Si un token de portador se transmite fuera de un canal seguro, una entidad malintencionada puede usar un ataque de tipo "man in the middle" para adquirir el token y usarlo para obtener acceso no autorizado a un recurso protegido. Se aplican los mismos principios de seguridad cuando los tokens de portador se almacenan o almacenan en caché para su uso posterior. Siempre asegúrese de que la aplicación transmita y almacene tokens de autenticación de forma segura.

Para conocer consideraciones adicionales sobre la seguridad del token de portador, consulte rfC 6750 sección 5.

Puede encontrar más información sobre los distintos tipos de tokens que se usan en Azure AD B2C en la referencia de tokens de Azure AD B2C.

Protocolos

Cuando esté listo para revisar algunas solicitudes de ejemplo, puede empezar con uno de los siguientes tutoriales. Cada uno corresponde a un escenario de autenticación determinado. Si necesita ayuda para determinar qué flujo es adecuado para usted, consulte los tipos de aplicaciones que puede compilar mediante Azure AD B2C.

• Compilación de aplicaciones móviles y nativas mediante OAuth 2.0
• Compilación de aplicaciones web mediante OpenID Connect