sushritpasupuleti / go-chi-boilerplate

Creating boilerplate for Go-chi with some good defaults. (Redis Caching, Postgres, JWT, OAuth2 and more)

Go-Chi Boilerplate

Creating boilerplate for Go-chi with some good defaults.

Note

This repository is updated infrequently, as I backport changes from my other projects into this. However, at any given point, the repo should be considered a good starting point.

Features

• Fully documented codebase with GoDoc.
• Logging with zerolog
• Routing with go-chi
• OpenAPI with go-swagger
• Input Validation with go-playground/validator
• Sane HTTP Security Headers with secure
• Custom Redis Cache Middleware with go-redis
  • Optional: Memcached implementation
• OAuth 2.0 client.
  • Password hashing with bcrypt
  • Token Grant
  • Token Validation + RBAC
  • Token Refresh
  • Token Revoke
• JWT authentication.

Setup

Run make to see all available commands.

Install dependencies

cd server
make packages_install

Run

cd server
make run

Notes on Design Considerations

• JWTIDs were used, but for the refresh token only. This is because the refresh token is persisted in the redis cache, and therefore needs to be revoked. The access token is not persisted, and therefore does not need to be revoked. This has the following benefits:

  • The access token doesn't need to be validated against the DB or cache, on each request. And instead the refresh token requires this only during a refresh.

  • This avoids too many DB/cache lookups, and therefore improves performance.

  • You can however, choose to use JWTIDs for both the access token and refresh token, if you want to prevent replay attacks.

Notes on storage of JWTs

• The API returns both an access token and a refresh token, it is recommended that the access token is stored in memory, and the refresh token is stored in a cookie with the secure & http-only flags set.

• The refresh token is also persisted in the redis cache for validation and revocation.

• Persisting the access token in memory, means that the token is not persisted across browser restarts, and is therefore more secure.

• Your client should refresh the access token when it expires, using the refresh token stored in the cookie.

• In case of higher security requirements, you can follow one of the following patterns:

  • Use a refresh token with a short expiry time, and refresh the refresh token on every request.

  • Omit the refresh token entirely, and use a short lived access token, and prompt the user to login again when the access token expires.

• You may also consider using JWTIDs, to prevent replay attacks.