The library provides multiple server-side authentication implementations and matching client-side implementations. It makes sense that these implementations need to be very specific on the server, but not so much on the client.
What I mean is that the code that implements JWT auth on the client actually has nothing at all specific to JWT and would work equally well for any Bearer authentication based system. I haven’t tried yet, but looking at the code, it looks like I can simply declare an API type using Auth '[JWT] and will be able to use the resulting client with any server that wants a Bearer token. However it will look weird.
So what I’m thinking is that it might be a good idea to define Bearer authentication solely in servant-auth-client and use the current JWT code for it and then also provide actual JWT instances going through the same code path.
Of course, there will only by HasClient for the resulting API type with Bearer and no HasServer.
The library provides multiple server-side authentication implementations and matching client-side implementations. It makes sense that these implementations need to be very specific on the server, but not so much on the client.
What I mean is that the code that implements
JWTauth on the client actually has nothing at all specific to JWT and would work equally well for anyBearerauthentication based system. I haven’t tried yet, but looking at the code, it looks like I can simply declare an API type usingAuth '[JWT]and will be able to use the resulting client with any server that wants a Bearer token. However it will look weird.So what I’m thinking is that it might be a good idea to define
Bearerauthentication solely inservant-auth-clientand use the currentJWTcode for it and then also provide actualJWTinstances going through the same code path.Of course, there will only by
HasClientfor the resulting API type withBearerand noHasServer.