OAuth2.0 and OpenID good practices

I've been recently interested in Oauth2.0 and the thin "layer" openID used to managed the Authentication part that OAuth does not really handle. I've read some articles, sometime contradictory, and watch a really good conference about it: https://www.youtube.com/watch?v=0VWkQMr7r_c. Unfortunatelly I was not in the audience so did not have a chance to ask my questions. Hopefully someone could answer them here :

OAuth2.0 specific questions:

1. There is a concept of back and front channel used during the authorization code flow. As far as I understood, the front channel is used to make the redirection to the authorization server and then back to the client application with the authorization code. Then this is the responsability of the back channel to exchange the received code against an access_token by requesting the authorization server with the code, client_id, client_secret and state parameters.

   Up until now it's ok but then when the back channel receives the access_token, how is my application supposed to handle it ? I mean, at the end, my client (so my application) is composed of a frontend (say VueJs) and a backend (let's say NodeJs). Then on the front end, the user (ressource owner) clicks on a button that's supposed to fetch some information on the ressource server. For that, the frontend needs to send a request to the ressource server with the access_token in the Authorization header. But the access_token is a sensitive data, so the frontend is not supposed to know about it right (only my backend knows about it right ?).

   Do I need to use my backend as a proxy and every request from my frontend that needs an access_token should first go through my backend that will add the access_token to the requet header and then forward it to the ressource server ? Or can I just store the acces_token inside the cookies so that my frontend can directly use it ? The former inevitably leads to having some sort of session cookie that my backend then uses to get the associated acces_token but then the securty is again impacted as my session cookie is on the front channel and it allows, just like the associated access_token, to query the ressource server (from the frontend point of view). The later seems contradictory with the goal of authorization code flow (hide the access_token from the browser) but I've seen some applications do that...

   In brief, I can't see how to benefit from the back channel concept since, at some point, the requests to the ressources server are originated from the frontend.

2. OAuth2.0 has a concept of refresh tokens that often live longer than access tokens and are used to get a new acces_token without going to the process of redirect to the authorization server, get the user consent and so on. But then what's the point of having short living acces_tokens if I can just use a refresh token (that lives for instance a year) and get a new access_token ? Short living tokens are "short living" only for security reasons but refresh_token seems to bypass the goal of those short living tokens. And thus why not have a refresh_token for ... another refresh_token ? Not sure if I'm clear but it seems to me that refresh tokens could just be replaced by long living acces tokens (the security impact is the same).

OpenID specific questions

3. If I understand correctly, OpenID is used to managed the authentication part plus adds some "standard" concerning OAuth2.0 (standard scope names, an endpoint that could be use to get the list of all endpoints/code flow/scope supported by the authorization server etc..). So at some point the authorization server will return to the client an id_token. Am I right when I way this token is not sensitive and can be stored in the cookies ?

4. How is the standard way to get the id_token on the client application. Looking at the RFC https://tools.ietf.org/html/rfc6749#page-19 I can only see 3 response types (code, token or a registered extension values, don't ask me about that). OpenID seems to add another response type: id_token (see https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationExamples). As a client, if i want both an access token and id token, do I need:

   • To send 2 separate requests, one with response_type=code the other with response_type=id_token
   • To send only one request with response_type=code but ad openID in the requested scope
   • To send only one requets with response_type=code id_token with/without openID in scope
   • Etc...

This is quite a long topic already so I'll stop my questions here. Thanks in advance for your answers.