oidc 在单点登录场景下是怎么使用的？ id_token,access_token 还是不太明白

最近在看了一点oidc相关的协议内容，想以此来做单点登录。但看了协议，还有好多不太明白的地方。

oidc相比oauth2来说, 多了一个id_token，用于身份认证，而本身oauth2部分的又有access_token及refresh_token，access_token是用于保护资源的，refresh_token是用于刷新access_token的.

那举个简单的使用场景:
一个平台，有以下几个服务， 统一身份认证的服务identify(基于oidc协议实现的idp) 服务 A(a.com) 服务 B(b.com) 那在 oidc 体系中，a.com, b.com 实际上是两个应用(client)

正常的流程就是:
a.com判断本地是否有token(基于localstorage是否有相关的存储)， 如果有，则每次正常请求携带token, 如果没有，则携带 client 信息(client_id,redirct_uri,scope 等)跳转至identify服务的登录页面， identify服务会对用户的用户名密码认证，认证成功后跳转至a.com/callback?code=xxxxx&state=xxx a.com 根据code码获取到id_token,access_token和refresh_token

那么有以下疑问：
问题 1: 前端中header头上使用的authorization是塞id_token还是access_token? 按照定义，应该是id_token吧。 那access_token的作用是不是如果我的资源只是限定有没有登录，登录就可以访问所有的资源(api 的鉴权有另外的鉴权服务)，那其实access_token在这种场景下就没有意义？

问题 2：refresh_token的作用是用来刷新id_token还是access_token? 因为refresh_token, access_token是 oauth2 就有的概念，最开始 refresh_token 肯定是刷 access_token 的， 那如果使用id_token，因为 jwt 的签发后无法回收，id_token理论上也是时效设置成比较短的一个时长，那这样必然是需要 refresh_token 去保证自动时长续期，所以可以使用返回的 refresh_token 值去 刷新 id_token 么？

问题 3：在多应用场景的单点登录下，比如a.com按照以上流程登录了，那理论上在同一个浏览器下，访问b.com应该也是登录状态的。那这个登录状态是怎么判断呢？b.com的本地存储里肯定是没有存储 id_token 的。 那此时，是不是在a.com登录的时候，登录成功其实就应该在identify的前端的localstorage里存储id_token？那这样问题又来了，刷新token了怎么办? 刷新 token 一般在应用端发起， 但又影响不到identify服务的前端存储. 没有想到比较完美的闭环