Cookie storage

[julienmeyer]

Hello,
First, thank you for your library.
I need to store the token in the cookies and not in the header.
I suggest to implement a JWTAuthTktAuthenticationPolicy. A mix between your policy and the cookie solution offers by Pyramid. Are you interrested by this solution ?
I can create a Pull request with my solution if you want.

[TWry]

+1

I'd be interested in this policy as well. It's not in your fork of pyramid_jwt, @julienmeyer , is it?

[wichert]

Auth_tkt is something quite different - I'm not sure it makes sense to create a mix of the two. I happen to find myself at a point where a cookie version of JWT may be useful as well, so I might be able to look at this somewhere in the next couple of weeks.

[julienmeyer]

I don't want to mix AuthTkt and JWT. I just want to use cookie as medium storage instead of http Authorization header field (with Secure and HttpOnly options). AuthTkt is probably not the good term in this case...

[ijames]

I came upon this issue when searching for a pyramid solution that implements the methodology described in this article: https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3

Basically, the JWT is split into two different cookies header.payload and signature with different cookie settings including expirations. I found their argument pretty compelling for using cookies and splitting up the JWT along with the independent expirations it provided.

Considering this auth strategy, using auth_tkt wouldn't work because two cookies would be needed.

It seems like this would be a pretty handy extension of JWT Auth using cookies versus LocalStorage.

[tholo]

I came upon this issue when searching for a pyramid solution that implements the methodology described in this article: https://medium.com/lightrail/getting-token-authentication-right-in-a-stateless-single-page-application-57d0c6474e3

Basically, the JWT is split into two different cookies header.payload and signature with different cookie settings including expirations. I found their argument pretty compelling for using cookies and splitting up the JWT along with the independent expirations it provided.

Considering this auth strategy, using auth_tkt wouldn't work because two cookies would be needed.

It seems like this would be a pretty handy extension of JWT Auth using cookies versus LocalStorage.

I think they are not so much saying "split into two cookies" as they are saying "split into a bearer token and an signature cookie" such that a single-page application will need to provide both the header (from code) and a cookie (from the browser) which have to match, and there the single-page application will not actually ever be able to see the cookie (it is http-only)?

That said, having such a capability would be nice, yes. But if the same end points are usable by both a single-page application (in a browser) and a native application just utilizing REST, there would maybe need to be a way to use both current (token only) and split (token + cookie)...?