Cookie Authentication

[kaptcha0]

I'm trying to enable cookie authentication with HC. Here is my current setup:

services
    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, opts => {
        opts.Cookie.Name = "auth";
        opts.SlidingExpiration = true;
        opts.ExpireTimeSpan = new TimeSpan(2, 0, 0, 0); // 2 day expiry
        opts.Cookie.HttpOnly = true;
        opts.Cookie.SameSite = SameSiteMode.Strict;

        opts.Events.OnRedirectToLogin = ctx => {
            ctx.Response.StatusCode = StatusCodes.Status401Unauthorized;
            return Task.CompletedTask;
        };
    });

For OnRedirectToLogin to get called, a login route must be specified. How would I do this with HC?

[ghost]

Using a cookie for a web api seems a poor choice. How should an api respond to a missing or invalid cookie? It can't redirect a client application to a login page, it can only return an "Unauthorized" HTTP error status, and hope the client will try again. Also, api calls need to be generated by application code, and so the client browser has no role in adding this cookie to the request automatically.

Here, you are really treating the cookie as an authentication token, and so using a token-based approach seems preferable. JWT is the obvious choice, and makes it clear which api endpoint is responsible for generating the token (e.g., a "login" mutation in HotChocolate), and that the token must be stored and included in the subsequent api calls by the application code.

This also allows the token creation to be handled by a completely different system (i.e., single-sign on) and the api to trust tokens issued by this system. The token can include all the necessary claims to authorize access to the data based on the user.

[kaptcha0]

I would like to stay away from JWT, because I want my users to have the ability to revoke access from any device. Client based authentication is exactly that, client based. There is no way to explicitly revoke a JWT token from the server side without adding some other token, hence a refresh token. Once you have that refresh token in place, why send a JWT in the first place? I should also mention that I'm moving away from the whole token-based system, as it is very inconvenient to implement, at least the method that I was using was. I envision a graphql query like:

query {
  login(username: "user1", password: "secure_password") {
    token
  }
}

with a response of:

{
  "login": {
    "token": "abcdefg12345"
  }
}

with token being one of the cookies, this way I have more control over what tokens are used. If it returns "Unauthorized" on the frontend/client side, I redirect to a login page. Simple as that.

[ghost]

There is quite a lot of discussion online for ways to support global token revocation for JWT. It seems to concentrate on how much additional data access you can tolerate on each request (since every web request will have to check if the token has been revoked). This would be true for your own format of access token.

Where JWT would win over your proposed "cookie" access token is the ability to encode claims directly in the token. This avoids the need to retrieve the user state associated with the "cookie" on every request from some additional storage, which gets expensive and/or complicated if you have a distributed back-end running across multiple servers.

A further benefit of JWT is simply avoiding the risks associated with building your own implementation, especially around security vulnerabilities.

Using JWT as the encoding of the access token does not mean you have to accept the rest of the expected processing, i.e., around trusting the token until it expires (which is probably still good to use in some form), or avoiding any sort of lookup of server-side data on every request. JWT is obviously trying to avoid generating database lookups per request by relying on the information encoded in the token, but this comes at a cost, such as the possible need for refresh tokens, or accepting the risk of the token being intercepted by a malicious actor.

JWT would also play nicer with any external authentication provider you might want to use in the future.

[kaptcha0]

The risk of a malicious actor using said token is what I am trying to mitigate by using the cookie, or any server-side access token, for that matter. The fact that there are no claims in the token means that there is a small chance that a bad actor can compromise the system by having the correct combination of claims, since there aren't any. Yes, a JWT would be better with external auth providers, but I'll cross that bridge when I get there.

Anyways, this has gotten derailed from the point of the question. I have my mind set on using cookie-based, server-side authentication, and I just want to know if there is some native way to integrate that with HC, and possibly Redis to store the token.