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
JwtAuthProvider(at domainA) that issues a JWT and associated cookies to a client.
UseTokenCookie=truewould of course be the case here. Since I want both the
ss-reftokto 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
Authorizationheader. In this case, I would not expect any cookies here, since it is a different domain, and so
UseTokenCookiewould be set to
falsefor 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
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
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.