Protegiendo el código del frontend para SPA + Restful API con OIDC

Tengo un SPA Angular 1 con una API Restful a la que me gustaría restringir el acceso. Como entiendo, normalmente el flujo implícito OIDC está diseñado solo para esto. Sin embargo, considero que el código de Frontend SPA también es sensible y me gustaría restringir el acceso a eso. Una implementación de vainilla del flujo implícito asume que el cliente de frontend es público y no lo hará.

La única forma práctica en que puedo pensar en proteger los activos de la aplicación es a través de una cookie. En mi opinión, hay algunas soluciones posibles:

1. Utilizar flujo de código de autorización:

   1. Usuario directo a la pantalla de inicio de sesión. El usuario inicia sesión.
   2. La pantalla de inicio de sesión devuelve la llamada al punto final de la API Restful que se ocupa del código de autorización.
   3. El punto final obtiene el token de actualización / acceso y genera su propio token de sesión.
   4. Endpoint redirige el navegador al SPA, enviándole el token de sesión en la porción de hash de la URL. En la misma respuesta, establezca solo HTTP, la cookie segura que contiene el token de sesión también.
   5. Sirve el SPA solo si la solicitud contiene una cookie con un token de sesión válido.
   6. Una vez en el SPA, analice el token de sesión del hash y utilícelo en el encabezado de Autorización para las solicitudes de API Restful.
      • Pros : me parece una forma legítima de utilizar el flujo de código de autenticación
      • Contras : se siente demasiado complicado. También tengo que administrar el estado de la sesión del lado del servidor como las aplicaciones web tradicionales.

2. Utilice el flujo implícito con una página de destino:

   1. Usuario directo a la pantalla de inicio de sesión. El usuario inicia sesión.
   2. La pantalla de inicio de sesión devuelve la llamada a una página de destino (un SPA), que analiza el token de acceso del hash y lo almacena en el almacenamiento local. La página de destino tiene el mismo dominio que el SPA protegido.
   3. La página de destino utiliza el token de acceso para realizar una solicitud de API Restful. El punto final de la API genera y establece una cookie segura, solo HTTP.
   4. La página de destino recibe la cookie y la redirige al SPA protegido.
   5. Sirve el SPA solo si la solicitud contiene una cookie válida.
   6. Una vez en el SPA, use el token de acceso de localStorage para realizar solicitudes de API Restful.
      • Pros : no se requiere estado del servidor
      • Contras : aún se siente un poco complicado, ahora necesito dos SPA.

3. Utilice el flujo implícito con los activos de la aplicación con carga lenta:

   1. Usuario directo a la pantalla de inicio de sesión. El usuario inicia sesión.
   2. La pantalla de inicio de sesión devuelve la llamada al SPA protegido. La parte no sensible del SPA es de acceso público.
   3. El SPA analiza el token de acceso y realiza una solicitud de API Restful. El punto final genera y establece una cookie segura, solo HTTP.
   4. El SPA recupera la cookie y carga de forma lenta el resto de la aplicación.
   5. El resto de los activos de la aplicación solo se cargan si las solicitudes contienen una cookie válida.
      • Pros : se siente más como un uso típico del flujo implícito, por lo que es más fácil razonar sobre su seguridad.
      • Contras : el SPA en sí es más complicado debido al requisito de carga lenta (pero quizás menos complicado que las otras dos soluciones)

¿Son estas soluciones razonables? ¿Hay alguna solución más simple todavía?