No debes permitir que tu página de autenticación / autorización se incruste en un IFrame, porque no puedes evitar los ataques de clickjacking de esa manera.
De RCF6749, Sección 10.13 "Clickjacking" :
Para evitar este tipo de ataque, las aplicaciones nativas DEBEN utilizar
Navegadores externos en lugar de integrar navegadores dentro de la aplicación
Al solicitar la autorización del usuario final. Para la mayoría de los navegadores más nuevos,
la evitación de iframes puede ser aplicada por el servidor de autorización usando
el encabezado de "x-frame-options" (no estándar). Este encabezado puede tener dos
valores, "deny" y "sameorigin", que bloquearán cualquier encuadre, o
Encuadre por sitios con un origen diferente, respectivamente. Para mayores
En los navegadores, se pueden utilizar técnicas de eliminación de marcos de JavaScript, pero no
Ser efectivo en todos los navegadores.
No es que el peligro aquí no sea que alguien superponga un botón invisible encima del iframe de su sitio, sino al revés: un atacante crea un botón de aspecto inocuo como "Mostrar lindos gatitos" y superpone su "Autorizar esta aplicación para acceder a todos mis datos "marco encima de eso. Cuando el usuario hace clic en el botón "gatitos", está dando acceso a su cuenta al atacante. La única forma de evitar eso es no permitir su flujo en un iframe. O simplemente asume el riesgo y vive con él.
Aparte de eso, debe tener cuidado con los tokens de portador: quien los posee tiene autorización, y se envían por cable para cada operación. Una vida útil de 30 días para algo como un access_token es una mala idea.
Para su propia aplicación, puede resolverla como le plazca, oauth2 ofrece el flujo de "Credenciales de propietario de recursos", que es una buena opción, en mi humilde opinión. Pero realmente no necesitas una verdad aquí.
Para sitios web de terceros, debe usar un flujo del lado del servidor con access_tokens de corta duración y refresh_tokens de larga duración que requieren autenticación del cliente (siempre que sea posible)
Para los consumidores del lado del usuario-agente (aplicaciones nativas), debe usar un flujo del lado del cliente con tokens de corta duración y tomar precauciones adicionales. O use algo diferente de oauth, oauth está muy centrado en la web.
PS : también me gustaría señalar que @HTLee comenta que la pregunta es incorrecta:
Para cualquiera que esté pensando en hacer esto, es mejor evitar al portador
enfoque simbólico. Si puede hacer uso de la concesión del código de autorización.
fluye, el token se almacena del lado del servidor y nunca se expone a la
navegador (más para la seguridad). Con una ficha de portador se acerca la ficha.
necesita ser expuesto al navegador
"Portador" es una propiedad del token que significa que "quien esté en posesión de esta cadena está autorizado". No está vinculado a un flujo particular y, de hecho, el flujo de "código de autorización" producirá un token de portador llamado access_token (y opcionalmente otro llamado refresh_token ).
La alternativa a los tokens "portadores" es un token MAC, que nunca se envía por cable. La especificación de tokens MAC en oauth2 no está estandarizada todavía.
Eso es lo que la publicación de Eran Hammer se trata y es solo tangencial a la pregunta de OP.