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
usingJwtAuthProvider
(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 thess-tok
andss-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 theAuthorization
header. In this case, I would not expect any cookies here, since it is a different domain, and soUseTokenCookie
would be set tofalse
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.