Estoy tratando de entender cómo una aplicación que usa el servidor OAuth2 (OIDC) implementaría el control de acceso a sus propios recursos.
En este caso, la aplicación es 'Cliente' y 'Servidor de recursos' en términos de OAuth2.
Entonces, el usuario, desde el navegador, accede a la aplicación y está siendo redirigido al servidor OIDC donde se autentica, después de lo cual el servidor OIDC envía access_token y id_token a la aplicación (no para el navegador del usuario, suponga que la aplicación es cliente "confidencial" en términos de OAuth2).
Supongo que este access_token podría emitirse con derechos de acceso a la aplicación (que ahora actúa como un 'Servidor de recursos'), que podrían usarse para controlar el acceso a los recursos de la aplicación para el usuario. Pero, ¿cómo podría el usuario enviar este access_token a la aplicación (actuando como un 'Servidor de recursos') ya que el usuario no obtuvo este token (solo se comparte con la aplicación)?
¿Es posible que este access_token se use para crear algún tipo de sesión de "acceso" entre el navegador del usuario y la aplicación, similar a la forma en que id_token se usa para construir sesión de autenticación en forma de una cookie? O, ¿se utiliza la sesión de autenticación para obtener access_token del servidor OIDC cada vez que un usuario accede a un recurso diferente en la aplicación, el usuario no está al tanto de esta comunicación, ya que no se le solicita su consentimiento?
¿O me estoy equivocando por completo?
Mi caso: supongamos que tenemos una aplicación web que tiene backend y frontend, pero el frontend NO se está implementando como un SPA (en cuyo caso actuaría como un 'Cliente'). El token todavía se comparte entre el backend y el AS (no pasa por el navegador). ¿Cómo mi aplicación controla el acceso a sus recursos? Por ejemplo, el usuario puede ver la página de inicio, pero no un portal de administración.
Por favor, no base sus respuestas en mi caso de uso concreto, trate de responder en general.
