Al actuar como un servidor de autorización (AS) que maneja OAuth 2.0, creo que las dos características principales de seguridad de la biblioteca que debe verificar son:
Evita que se pierda el token de acceso al restringir la URL de redireccionamiento . En el flujo implícito, el AS recibe una concesión de autorización de un cliente en el que no puede confiar. Para no otorgar tokens de acceso a nadie, la biblioteca debería permitirle especificar una lista (blanca) de URL para cada cliente que se conecte. En la prueba de penetración, debe verificar si puede usar una URL en redirect_url que no coincida con una de las URL en la lista blanca (sería un error).
Cómo evitar la falsificación de solicitudes y / o la fijación de sesión entre sitios con el parámetro de estado . El parámetro de estado es un valor aleatorio, generado por el cliente. El parámetro siempre se incluirá en la comunicación posterior con el AS. Permite al cliente validar que el token de acceso que recibe corresponde a la solicitud de autorización precedente. Sin este parámetro, un atacante podría inyectar su propio token de acceso y, por lo tanto, otorgar acceso a los recursos que controla el atacante. El usuario final, entonces, por ejemplo. Publicar sus datos en la cuenta del atacante. Por lo tanto, para la prueba de penetración, debe verificar si la biblioteca valida correctamente el parámetro de estado o si puede modificar el valor.
Ah, y casi lo olvido: OAuth 2.0 especifica claramente que se basa en el transporte seguro SSL / TLS. Entonces, si no está prestando servicio exclusivo a su AS a través de HTTPS, ese es un gran #FAIL en el informe de la prueba de penetración.
La especificación inicial OAuth 2.0 RFC 6749, sección 10 ya contiene muchas consideraciones de seguridad. Además, hay un RFC adicional dedicado a la seguridad de OAuth 2.0: enlace
Otro gran recurso que resume todo se puede encontrar aquí: enlace