JwtAuthProvider without cookies

#1

I’m investigating an issue with JwtAuthProvider that kind of makes it very difficult to get auth setup right in a distributed environment, for local testing. I think I suggest a fix.

Assuming an architecture where:

  • I have an AuthNServer using JwtAuthProvider (at domainA) that issues a JWT and associated cookies to a client. UseTokenCookie=true would of course be the case here. Since I want both the ss-tok and ss-reftok to go back to the client, to support local calls to that server and refresh token flow etc.
  • I also have one or more APIs using JwtAuthProviderReader (at domainB) that verifies the JWT that is expected in the Authorization header. In this case, I would not expect any cookies here, since it is a different domain, and so UseTokenCookie would be set to false for self-documentation purposes in the code, and to be explicit about what is expected here.

However, in local testing, where domainA is realized as localhost:5001 and domainB is realized as localhost:5003, (using multiple ports is a common pattern for medium sized products in local dev and testing) things get a little weird. Since we are actually on the same domain now as the AuthNServer - and the cookies starts getting used inadvertently by the API when the JwtAuthProviderReader reads the JWT from the Request.

In this case, explicitly setting UseCookieToken=false does not have the intended effect of demanding that the JwtAuthProviderReader does not use the ss-tok cookie for the source of the JWT token, and force it to look only in the Authorization header, because of this code:

I wonder if I could suggest that we only look for the ss-tok (req.GetCookieValue(Keywords.TokenCookie)) if UseTokenCookie==true?

Or would that mess things up?

I’m finding holes in manual testing and automated tests where the ss-tok is being a shadow for a missing Authorization header, and I’d rather pick those erros up in tests, rather than in production code.

#2

You can use different localhost domains to isolate cookies, e.g: localhost:5001 and 127.0.0.1:5003.

#3

True, but it’s pretty ugly, and unintuitive for the inexperienced developers.

Prefer to be explicit about all this in configuration options, rather than unexpected behavior happening just because of happenstance.

To be clear I’m suggesting this change:

var jwt = req.GetBearerToken();
if (jwt == null && UseTokenCookie)
{
    jwt = req.GetCookieValue(Keywords.TokenCookie);
}

return jwt;

Worth submitting a PR?

#4

That would break clients who’ve specified to use JWT Token Cookies at authentication or who’ve explicitly configured it themselves on their HTTP clients. If clients sends the Token via the cookie, that’s typically how they’ve chosen to authenticate.

#5

OK, fair enough then

#6

FYI you can now override these implementations in your AppHost:

  • GetAuthorization(IRequest req)
  • GetBearerToken(IRequest req)
  • GetJwtToken(IRequest req)

Now available from latest v5.10.5+ that’s now on MyGet.

#7

We’ve had some issues trying to run a pure jwt environment. It would be nice if there were a safe and easy way to turn off cookie support completely, and/or an easy path to running pure jwt, as we found the cookies to come back and bite us when we are sending a bearer token saying X, yet there is a cookie saying Y.

Once we noticed these issues, we resorted to some global filters to try and remove them from coming in and going out, but still we see them in the headers. Internally we’ve pretty much naturalized them and seem to have our pure jwt solution working pretty good now, but starting out we too ran into these issues and it would have been nice to have what you are describing here. A definite way to turn off the cookie auth stuff, and/or easier to run pure jwt.

My two pennies

#8

You can override SetCookieFilter() in your AppHost and return false on any of the cookies you don’t want set, which lets you explicitly disable session cookies with:

SetConfig(new HostConfig {
    AllowSessionCookies = false
});

Not sure you want to turn off cookies for JWT though as it’s recommended for Web Apps to use JWTs in Secure HttpOnly cookies.

1 Like
#9

Ahh Thanks @mythz! I see this is a new pattern you are now supporting. Just when I thought I was getting away from cookies… Will have to keep this in mind going forward.

1 Like