abraithwaite/jeff

🍍Jeff provides the simplest way to manage web sessions in Go.

jeff

A tool for managing login sessions in Go.

Motivation

I was looking for a simple session management wrapper for Go and from what I could tell there exists no simple sesssion library.

This library is requires a stateful backend to enable easy session revocation and simplify the security considerations. See the section on security for more details.

Features

• Redirect to login
• Middleware wrapper
• Easy to clear sessions
• Small, idiomatic API
• CSRF Protection
• Context aware
• Fast
• Multiple sessions under one key

Requirements

The module uses msgpack for encoding and requires a recent version of Go to function. It's recommended to have a version no older than 1 year, but there's a hard requirement to have at least Go 1.11+. Tests are only done against the latest stable version of Go.

Usage

There are three primary methods:

Set starts the session, sets the cookie on the given response, and stores the session token.

func (s Server) Login(w http.ResponseWriter, r *http.Request) {
    user = Authenticate(r)
    if user != nil {
        // Key must be unique to one user among all users
        err := s.jeff.Set(r.Context(), w, user.Email)
        // handle error
    }
    // finish login
}

Wrap authenticates every http.Handler it wraps, or redirects if authentication fails. Wrap's signature works with alice. The "Public" wrapper checks for an active session but does not call the redirect handler if there is no active session. It's a way to set the active session on the request without denying access to anonymous users.

    mux.HandleFunc("/login", loginHandler)
    mux.HandleFunc("/products", j.Public(productHandler))
    mux.HandleFunc("/users", j.Wrap(usersHandler))
    http.ListenAndServe(":8080", mux)

Clear deletes the active session from the store for the given key.

func (s Server) Revoke(w http.ResponseWriter, r *http.Request) {
    // stuff to get user: admin input form or perhaps even from current session
    err = s.jeff.Clear(r.Context(), user.Email)
    // handle err
}

The default redirect handler redirects to root. Override this behavior to set your own login route.

    sessions := jeff.New(store, jeff.Redirect(
        http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            http.Redirect(w, r, "/login", http.StatusFound)
        })))

This is primarily helpful to run custom logic on redirect:

    // customHandler gets called when authentication fails
    sessions := jeff.New(store, jeff.Redirect(customHandler))

Design

Session tokens are securely generated on Set (called after successful login). This library is unique in that the user gets to decide the session key. This is to make it easier for operators to manage sessions by not having to track/store session tokens after creating a session. Session keys don't have to be cryptographically secure, just unique per user. A good key that works for most people is the user's email.

The cookie format is as follows:

CookieName=SessionKey::SessionToken

The SessionKey is used to find the given session in the backend. If found, the client SessionToken is then constant-time compared with the stored token.

Sessions are stored in the backend as a map from the application-chosen session key to a list of active sessions. Sessions are lazily cleaned up once they expire.

Security

Most of the existing solutions use encrypted cookies for authentication. This enables you to have stateless sessions. However, this strategy has two major drawbacks:

• Single ultra-secret key.
• Hard to revoke sessions.

It's possible to alleviate these concerns, but in the process one will end up making a stateful framework for revocation, and a complicated key management strategy for de-risking the single point of failure key.

Why aren't we encrypting the cookie?

Encrypting the cookie implies the single secret key used to encrypt said cookie. Programs like chamber can aid in handling these secrets, but any developer can tell you that accidentally logging environment variables is commonplace. I'd rather reduce the secrets required for my service to a minimum.

CSRF Protection

This library also provides limited CSRF protection via the SameSite session cookie attribute. This attribute (implemented in modern browsers) limits a Cross Origin Request to a subset of safe HTTP methods. See the OWASP Guide for more details.

Development

Clone the repo, run docker-compose up -d, then run make test.

With the local redis instance running, you can then run the example application: go run ./cmd/example/main.go.

Limitations

Also excluded from this library are flash sessions. While useful, this is not a concern for this library. If you need this feature, please see one of the libraries below.

Race Conditions

There is a race condition inherant in how this library handles expiration and deletion of sessions. Because sessions are stored as a list for each user, to add, delete, or prune sessions, it's required to do a read, modify, write without any kind of transaction. That means that it's possible, for example, for a new session to be wiped out if it's created between reading and writing in another concurrent read-modify-write operation, or for a session which was meant to be cleared, didn't get cleared because the clear was issued during another processes' modify step in the read-modify-write cycle.

In practice, this should be quite rare but for people considering this for short-lived sessions with high numbers of concurrent sessions per user, you might want to reconsider.

Alternatives

The most popular session management tool is in the gorilla toolkit. It uses encrypted cookies by default. Has a very large API.

https://github.com/gorilla/sessions

A comprehensive session management tool. Also a very large API. Heavy use of naked interfaces.

https://github.com/kataras/go-sessions

Encrypted cookie manager by default. Has middleware feature. Big API. No easy way to clear session without storing session token elsewhere.

https://github.com/alexedwards/scs

Lightweight, server-only API. Uncertain about what the purpose of the Manager interface is. Heavy use of naked interface.

https://github.com/icza/session

Lightweight, server-only API. Includes concept of Users in library. No wrapping or middleware.

https://github.com/rivo/sessions

Batteries-included middleware for keeping track of users, login states and permissions. Very large API.

https://github.com/xyproto/permissions2

jeff's Issues

Session Metadata

Provide ability to store generic session metadata with session (binary blob).

Comparison to github.com/alexedwards/scs

A quick look at both libraries seems to show an important difference: github.com/alexedwards/scs buffers all response bytes. A bufferedResponseWriter{} buffering all output to catch session changes before headers are sent (

• https://github.com/alexedwards/scs/blob/master/session.go#L118
• Which at one point supported websockets by implementing hijack?.

Jeff seems to handle this better (but not easier) by making you call Set manually when headers should be set without wrapping your http.Handler.

Don't use alexedwards/scs if you send large payloads to clients, stream response bodies, use websockets(?), etc.

sessions: Clear doesn't return potential error

Clear function in sessions.go doesn't handle the return value of the clear function.

jeff/sessions.go

Line 225 in a6a878d

j.clear(ctx, s.Key)

Multiple sessions per key

Currently, each session requires a unique key. Would be nicer if we stored a list of sessions for each key.

Can you use the cookie as a storer?

Can you use the cookie as a storer for the session instead of a backend like redis and others?

No way to delete a single session for a given user

Currently, user's sessions are stored as a list of active sessions under a single key in redis, each with their own unique token.

When we moved to this model, we didn't update the Clear and Delete methods to be able to clear just an individual session. As it stands, calling either of these methods will terminate all active sessions instead of just one, as it was originally intended.

chroot key prefix for caches

Add this for shared cache scenarios

Evaluate using gokv as storage interface

Hi, I saw your project in my GitHub feed because someone I follow starred it and when seeing the Storage interface I immediately thought that it would be a great fit for a project of mine: https://github.com/philippgille/gokv

I'll paste the code here so you don't have to follow the links:

jeff.Storage:

type Storage interface {
	Store(ctx context.Context, key, value []byte, exp time.Time)
	Fetch(ctx context.Context, key []byte) (value []byte, err error)
	Delete(ctx context.Context, key []byte) error
}

gokv.Store:

type Store interface {
    Set(k string, v interface{}) error
    Get(k string, v interface{}) (found bool, err error)
    Delete(k string) error
    Close() error
}

Downsides:

• gokv doesn't work with contexts yet
• There's no expiration handling in the implementations, but you can save the whole item (that includes the expiration) and similarly to your memory implementation (here), just not return it when it's expired.

Upsides:

• The main upside is the number of implementations for the interface. There's a simple Go map, sync.Map, FreeCache, BigCache, bbolt (a.k.a. BoltDB), BadgerDB, LevelDB, Local files, Redis, Consul, etcd, Apache ZooKeeper, Memcached, Hazelcast, Amazon DynamoDB, Amazon S3, Azure Table Storage, Google Cloud Datastore, Alibaba Cloud Tablestore, MySQL, PostgreSQL, MongoDB, CockroachDB and Apache Ignite. And more to come :)
• All implementations allow to save any struct instead of just a slice of bytes. That's useful for example to include the expiration when storing a session and allows extending the stored struct with more fields in the future

This is exactly the use case that I had in mind when creating it: As a package creator you want your package users to to be able to use as many storage implementations as possible, so you only use a common key-value interface and then point package users to existing implementations.

Maybe you can have a look at it and then I'd love to hear what you think :)

Can I replace authboss with yours?

Excuse the question maybe very basic for you, but I'm learning day by day and I want to understand well.

I am using authboss for a hobby project.

But I do not need most of its features: I would just like to authenticate a user (email and password) if he has to use specific APIs.

Do you think I can replace authboss with your project?

Add control of SameSite prefix

For our application, we need our session cookies to have SameSite=None. SameSite=lax is hardcoded in the cookie setup, here:

jeff/sessions.go

Line 198 in ade959f

w.Header().Set("Set-Cookie", w.Header().Get("Set-Cookie")+"; SameSite=lax")

Can SameSite's setting become an Option on jeff.New()?

sessions: load all sessions for user

Hi @abraithwaite!
First of all, I want to say thanks a lot for this package, I found out that popular packages were lacking for my use-case where I want to search sessions by user-id.

However, after taking a look around, I couldn't find an exported function to get all active sessions for a user.
This is helpful, for example, if the user is logged in from many devices and we want to revoke them all at once.

Thoughts?

Rename Package

I'm not in love with the name of the repo.