Pruebas automatizadas de API de OAuth2/OpenID Connect protegido API

openid-connect acceptance-testing

Question

Estoy investigando un nuevo proyecto en el que estamos planeando hacer API primero, para poder implementar aplicaciones web y nativas además de permitir la integración de terceros. Todo bastante estándar hasta ahora.

También queremos tener un conjunto completo de pruebas automatizadas para la API, tanto para garantizar que funciona sin regresiones, como para garantizar que cumpla con los requisitos. De nuevo, bastante estándar, pero como estamos probando la API, usaremos un cliente HTTP de código y no un navegador web.

Hemos estado buscando auth2 / OpenID Connect para facilitar la autenticación y autorización de la API, básicamente, para que los clientes puedan autenticarse, obtener un token de acceso y luego usarlo para acceder a todos los recursos de la API.

Lo que me cuesta trabajo es una buena manera de hacer que las pruebas automatizadas funcionen con la parte oauth2 para poder llamar a la API. La primera idea fue utilizar los tipos de concesión "client_credentials" o "password", que parecen funcionar con lo que queremos, pero no están cubiertos por la especificación de OpenID Connect y, por supuesto, la "contraseña "Uno al menos no se considera una buena idea de todos modos.

¿Es esta la mejor manera de lograr esto o existen otras mejores prácticas para este tipo de situación que se pueden usar con los otros flujos, pero sin un navegador web?

Edit: después de (mucho) más lectura, tengo un nuevo plan. Ejecutar pruebas completamente fuera de línea, usar una implementación separada en una base de datos separada y sembrar datos directamente en la base de datos antes de que se ejecuten las pruebas, y luego usar los flujos estándar de OpenID Connect, pero con:

• Un cliente que está marcado en la base de datos para propósitos de prueba. Este es un bit importante, y solo es posible si el cliente puede registrarse directamente en la base de datos sin pasar por la lógica empresarial.
• indicador = ninguno
• login_hint = el nombre de usuario para obtener un token de acceso para
• alcance que contiene "pruebas"

Luego, el sistema puede detectar esta combinación de hechos y autenticar automáticamente el nombre de usuario proporcionado sin necesidad de pasar por un navegador.

¿Esto parece razonable? ¿O hay un mejor camino?

Answer 1

Ya que está buscando probar la API, no debería importar cómo obtuvo access_token , a través del navegador o de alguna otra manera. Así que hay (al menos) dos soluciones:

1. Esa otra forma podría ser la subvención client_credentials . Tendrá que hacer que el Servidor de Autorización devuelva un access_token que se asemeja a un access_token que se devolvería para un usuario en un flujo de OpenID Connect a través del navegador pero dependiendo de la implementación de AS que debería ser factible.

2. Arranque a su cliente usando un flujo regular de navegador OpenID Connect para generar un refresh_token junto a un access_token y almacene ambos tokens con su cliente de prueba junto con el client_id y client_secret en el momento de la configuración. Su cliente de prueba puede acceder a las API hasta que el access token caduque y, posteriormente, obtener un nuevo access_token través del tipo de concesión refresh_token (aprovechando el client_id y el client_secret ).

OpenID Connect en sí mismo, la autenticación del usuario y el id_token son irrelevantes para sus API que deberían preocuparse solo por el access_token .