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

Question

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.

Answer 1

When you talk about JWT, I guess you are talking about the id_token which is the only token which is required to be a JWT by OpenID Connect.

You can actually do better than that. Your frontend actually does not need to keep the id_token and, when using the authorization code flow, does not need to ever see the id_token, access_token and refresh_token at all. All your frontend has to see is the authorization code.

What you can do is store a (HTTP only) session cookie in the frontend (eg. JSESSIONID, PHPSESSID):

1. When you start the OpenID Connect dance, the backend generates a state, nonce, code_verifier and code_challenge and associates all of that to the session.
2. Your backend generates an authentication request.
3. At some point, the OpenID provider sends back the state parameter and authorization code to your application.
4. Your backend checks that the state is the one which is stored in the session, does several additional verifications.
5. Your backend exchanges the code it received with the id_token, access_token and refresh_token.
6. Your backend generates a new session and associates these tokens with this new session.

As you see, in this workflow, the frontend:

• never sees any id_token, access_token, refresh_token;
• sees the authorization code;
• might see the state and code_challenge (unless Pushed Authorization Requests which you should use if you can).

In this example, the session ID was stored as a HTTP only cookie but it could be stored through some other mechanism if needed.

I think HTTP-only Cookie as a JWT carrier is possible because all my client applications, resource servers

You are talking about resource servers, are you really talking about OpenID Connect of about OAuth in general?