OAuth2

Prenly soporta OAuth2 con o sin extensión OpenID Connect (OIDC) siempre que el servidor de autorización siga la especificación OAuth2 RFC 6749. Es probable que necesite un servidor de autorización que admita OIDC.

Prenly sólo admite la concesión de autorización Código de autorización.

El cliente que Prenly utilizará en el flujo OAuth2 es la autoridad de aplicación del e-paper (una implementación técnica que decide cómo la autenticación y la autorización son gestionadas por la aplicación e-paper dentro del backend de Prenly).

Prenly necesitará saber algunas cosas para poder actuar como cliente del flujo de autorización:

- Opcional*. El emisor elegido.
Esto sólo es obligatorio si desea utilizar la extensión de OpenID Connect ID token claim.

- Obligatorio. El ID de cliente que desea que utilice la autoridad Prenly.

- Obligatorio. El secreto de cliente que desea que utilice la autoridad de Prenly al intercambiar la concesión de autorización proporcionada por un token de acceso al autenticar la autoridad de Prenly (el cliente).

- Opcional. Alcance. Puede elegir que Prenly utilice una lista separada por espacios de ámbitos que definen el permiso del token emitido. Los ámbitos se utilizarán con el punto final de autorización.

- Opcional. Estado. Prenly admite la generación de estado en la solicitud de autorización. Puede elegir entre dejar que Prenly genere un estado o hacer que la autoridad lo omita.

- Obligatorio. Punto final de autorización. La autoridad de Prenly dirigirá al agente de usuario a este punto final para iniciar el flujo de autorización con el servidor de autorización mediante el registro del usuario para obtener la concesión del código de autorización.

- Obligatorio. Token endpoint. La autoridad Prenly intentará intercambiar el código de autorización del usuario por un token de acceso o, si su servidor de autorización lo admite (lo cual es muy recomendable), intercambiar el token de actualización del usuario por un nuevo token de acceso.

Método de autenticación. Por defecto, Prenly utiliza el método de autenticación de cliente client_secret_basic de OIDC cuando se autentica con el token endpoint del servidor de autorización. Prenly también admite el método de autenticación de cliente client_secret_post. Notifique a Prenly si necesita este último, de lo contrario se utilizará el método de autenticación por defecto.

- Recomendado. Una URL externa para cerrar la sesión del usuario. La autoridad de Prenly utilizará el agente de usuario seleccionado por el usuario actual para cerrar la sesión del usuario de forma remota en el servidor de autorización.
Prenly es capaz de utilizar marcadores de posición en la URL al crear la solicitud de autorización para cerrar la sesión del usuario proporcionando lo siguiente:

◦ El ID de cliente;
◦ El URI de retorno de cierre de sesión;
El URI de error de cierre de sesión;

Tenga en cuenta que no se puede utilizar el estado.
Un ejemplo de parámetro de consulta URI de retorno es "post_logout_redirect_uri".

Actualmente, sólo se admite el método HTTP GET para la URL de cierre de sesión.

ID de usuario

La autoridad Prenly necesitará saber cómo extraer el ID de usuario único después de que el usuario haya sido autorizado con éxito por el servidor de autorización.

Este ID de usuario único, si está utilizando la API de autoridad remota de Prenly, es el parámetro de solicitud `uid` cuando se solicita la información de resumen del usuario.

Puede elegir uno de los siguientes métodos:

- Desde una propiedad en la respuesta del punto final del token JSON. Si elige esta opción, debe informarnos del nombre de la propiedad elegida que contiene el ID de usuario.

- De la declaración "sub" de OpenID Connect en el token de ID firmado (tal y como devuelve la propiedad de respuesta del token "id_token".
Para poder extraer el ID de usuario también debe proporcionar:

◦ Obligatorio. La URL externa a las claves públicas para validar los tokens de ID. Esta URL debe contener un conjunto de claves web JSON según los estándares JWT, que puede denominarse JKU o JWKS.
◦ Opcional. El nombre de la propiedad en la respuesta de datos de usuario que contiene un número de cliente.

- De la respuesta de propiedad "sub" de un endpoint UserInfo.
Para utilizar este método también debe proporcionar:

◦ Obligatorio. La URL del punto final de UserInfo. El endpoint se utiliza para obtener información básica sobre el usuario utilizando el token de acceso del usuario para autorizar la solicitud.
◦ Opcional. El nombre de la propiedad en la respuesta de datos de usuario que contiene un número de cliente.

Servidor de recursos.

Puede elegir un servidor de recursos que admita Prenly o puede ponerse en contacto con nosotros en hello@prenly.com para solicitar a Prenly que admita su servidor de recursos específico como tarea de integración, que Prenly podría admitir en función de una tarea de desarrollo de pago.

Prenly es compatible con la API de autoridad remota de Prenly a partir de la versión 1.4 como servidor de recursos. Consulte nuestra información general sobre la API de autoridad remota de Prenly para conocer el concepto de esta API. Para implementar la API de autoridad remota de Prenly como servidor de recursos, consulte la especificación de la API para el punto final /oauth2/getUser.

El "recurso" que Prenly solicita al servidor de recursos es una lista de productos de suscripción asociados al usuario. Los productos, en forma de código de producto, indican el estado de suscripción del usuario, donde cada código está configurado para conceder acceso de lectura a las publicaciones dentro de su aplicación e-paper.

Para conceder el acceso de lectura correcto en función del producto de suscripción, también debe informar a Prenly de las publicaciones a las que el código de producto autoriza el acceso de lectura. Cualquier producto desconocido será ignorado.

Puede que no necesite un servidor de recursos dedicado...

Prenly puede omitir por completo un servidor de recursos tradicional si su punto final UserInfo es capaz de exponer el estado de suscripción del propietario del recurso: el usuario.

Si su punto final UserInfo es capaz, todo lo que tendrá que proporcionar es la reclamación (nombre de la propiedad) en los datos JSON de la respuesta del punto final UserInfo.

El valor de la reclamación debe ser una lista JSON (matriz) de cadenas. Cada elemento de la lista representa un código de producto de suscripción.

Proporcionar información

Cuando tenga toda la información requerida, póngase en contacto con el servicio de atención al cliente de Prenly en hello@prenly.com con la información. A continuación, el equipo configurará la autoridad Prenly de la aplicación de papel electrónico elegida para que utilice OAuth2 por usted.