Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CookieSettings required despite only using JWT Auth #1576

Open
ChrisPenner opened this issue Apr 7, 2022 · 2 comments
Open

CookieSettings required despite only using JWT Auth #1576

ChrisPenner opened this issue Apr 7, 2022 · 2 comments

Comments

@ChrisPenner
Copy link

ChrisPenner commented Apr 7, 2022

Hi all 👋🏼

I've been setting up auth for my server using servant-auth and servant-auth-server I've run into a few different issues, first for a bit of context:

  • We're using JWT access tokens for our authentication, the tokens contain only a signed user ID which we then use to look up the user attributes in a DB
  • We don't really have any use for cookie auth or sessions at the moment.

Pursuing this goal, I added the following type:

data AccessTokenClaims = AccessTokenClaims
  { userID :: UserId,
    scope :: Scopes
  }

instance FromJWT AccessTokenClaims where
  decodeJWT :: ClaimsSet -> Either Text AccessTokenClaims
  decodeJWT claims = do
    
    userID <- fromMaybe (Left "Invalid sub") (claims ^? claimSub . _Just . JWT.string . to IDs.fromText)
    pure (AccessTokenClaims {..})
    where
      resultEither = \case
        Aeson.Error err -> Left (Text.pack err)
        Aeson.Success a -> Right a

Now I use Auth '[JWT] AccessTokenClaims in my API routes, but my call to hoistServerWithContext complains:

    • No instance for (HasContextEntry '[] CookieSettings)
        arising from a use of ‘hoistServerWithContext’

Which is strange because I'm not reading or setting cookies anywhere, nor do I intend to.

I've read elsewhere that servant-auth sets session cookies for all users regardless of whether you want it to, and as a result ALSO requires a ToJWT instance on anything that Auth returns. This is at worst an annoyance for AccessTokenClaims, but I proceeded to add a custom combinator which reads and validates the jwt, and then loads the user from our DB:

type AuthedUser = Auth '[UserByJWT] User

data UserByJWT

instance IsAuth UserByJWT User where
  type AuthArgs UserByJWT = '[PG.Connection, JWTSettings]
  runAuth _ _ conn jwtSettings = do
    AccessTokenClaims {userID} <- jwtAuthCheck jwtSettings
    mayUser <- liftIO $ runReaderT (PG.userByUserId userID) conn
    maybe (fail "User not found") pure mayUser

The idea here is to allow loading the authenticated user for all requests which need it.

However once again I'm told that I need ToJWT for User, which implies that Auth wants to save User in a session cookie. I don't want the User to be saved in a session cookie, not only is it potentially large, but it may hold sensitive information that shouldn't leave the server.

It seems like this isn't how Auth is intended to be used, but simultaneously seems like the most sensible way to load an authenticated user safely.

I suspect I could write my own combinator to do this which circumvents servant-auth entirely, or I can just load the user inside every endpoint which requires it; but figured I'd ask whether this is something servant-auth supports somehow first.

@gdeest
Copy link
Contributor

gdeest commented Apr 8, 2022

The HasServer instance for Auth does depend on cookie settings being present in the context anyhow:

https://hackage.haskell.org/package/servant-auth-server-0.4.7.0/docs/Servant-Auth-Server.html#t:HasServer

To be clear, I do think it is a design wart: the instance should be independent on the authentication scheme. There is a draft PR that intends to solve this problem:

#1560

@ChrisPenner
Copy link
Author

Awesome, glad to see there's a PR in the works. For now I guess I'll use one of the work-arounds I mentioned 👍🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants