OIDC with JWT in HTTP-only cookie instead of HTTP Authorization bearer header

OIDC with JWT in HTTP-only cookie instead of HTTP Authorization bearer header

I'm exploring the possibility of implementing OpenID Connect (OIDC) with an HTTP-only cookie to keep my frontend code completely authentication-agnostic, instead of passing the Authorization header around through Javascript code. The idea behind this is that front-end developers don't have to worry about authentication.

• My frontend is a SPA build with Javascript and HTML and consists only of static files.
• My backend is a REST API, with no UI.
• I want to use OIDC Implicit Flow but my Authorization Server sets the HTTP-Only cookie with access_token JWT, instead of passing the token back as a query parameter.
• I believe that by using an HTTP-Only cookie, I can make Implicit flow as secure as Authorization Code with PKCE flow because the token is not exposed as a URL parameter when redirecting back to the client after a successful login.

I think HTTP-only Cookie as a JWT carrier is possible because all my client applications, resource servers, and the login screen are on the same origin. HTTP-Only cookies are also invisible to Javascript code, therefore they are inherently secure against XSS attacks. Especially I want my frontend-applications not to use auth-token grant, replacing it with access_code being set in the JWT cookie already, so that first call to /token endpoint could be skipped, which I believe removes a lot of complexity from the frontend part.

The only thing my front-end could do is intercept handling HTTP responses from AJAX calls using Fetch API (I could achieve it with a simple wrapper around fetch() function, I could provide it in a mini JS library that frontend developers should use). So that 401 and 403 status codes would redirect users to the login screen.

What are the security implications of such a setup? Specifically, I am interested in how to handle:

• CSRF-tokens, I see some resources recommend using SameSite=Strict cookie attribute, but is it enough? I probably still want to use CSRF-token, but how could I validate on the resource-server side?
• Similarly, how should I deal with Refresh-Tokens? Should I still have a /token endpoint with refresh_token grant-type support? Should I also keep the refresh tokens in HTTP-only cookie in that case?

Please indicate any security issues this kind of setup has, or suggest alternative ways. Please consider that my application frontend is completely static, and there is no way to generate HTML or Javascript in the backend.