jwt_sessions
XSS/CSRF safe JWT auth designed for SPA
Table of Contents
- Synopsis
- Installation
- Getting Started
- Creating a session
- Rails integration
- Non-Rails usage
- Configuration
- Token store
- JWT signature
- Request headers and cookies names
- Expiration time
- Exceptions
- CSRF and cookies
- Refresh with access token
- Refresh token hijack protection
- Flush Sessions - Sessions namespace - Logout
- Examples
- Contributing
- License
Synopsis
The primary goal of this gem is to provide configurable, manageable, and safe stateful sessions based on JSON Web Tokens.
The gem stores JWT based sessions on the backend (currently, Redis and memory stores are supported), making it possible to manage sessions, reset passwords and logout users in a reliable and secure way.
It is designed to be framework agnostic, yet easily integrable, and Rails integration is available out of the box.
The core concept behind jwt_sessions
is that each session is represented by a pair of tokens: access
and refresh
. The session store is used to handle CSRF checks and prevent refresh token hijacking. Both tokens have configurable expiration times but in general the refresh token is supposed to have a longer lifespan than the access token. The access token is used to retrieve secure resources and the refresh token is used to renew the access token once it has expired. The default token store uses Redis.
All tokens are encoded and decoded by ruby-jwt gem. Its reserved claim names are supported and it can configure claim checks and cryptographic signing algorithms supported by it.
jwt_sessions
itself uses ext
claim and HS256
signing by default.
Installation
Put this line in your Gemfile:
gem "jwt_sessions"
Then run:
bundle install
Getting Started
You should configure an algorithm and specify the signing key. By default the gem uses the HS256
signing algorithm.
JWTSessions.signing_key = "secret"
Authorization
mixin provides helper methods which are used to retrieve the access and refresh tokens from incoming requests and verify the CSRF token if needed. It assumes that a token can be found either in a cookie or in a header (cookie and header names are configurable). It tries to retrieve the token from headers first and then from cookies (CSRF check included) if the header check fails.
Creating a session
Each token contains a payload with custom session info. The payload is a regular Ruby hash.
Usually, it contains a user ID or other data which help identify the current user but the payload can be an empty hash as well.
> payload = { user_id: user.id }
=> {:user_id=>1}
Generate the session with a custom payload. By default the same payload is sewn into the session's access and refresh tokens.
> session = JWTSessions::Session.new(payload: payload)
=> #<JWTSessions::Session:0x00007fbe2cce9ea0...>
Sometimes it makes sense to keep different data within the payloads of the access and refresh tokens.
The access token may contain rich data including user settings, etc., while the appropriate refresh token will include only the bare minimum which will be required to reconstruct a payload for the new access token during refresh.
session = JWTSessions::Session.new(payload: payload, refresh_payload: refresh_payload)
Now we can call login
method on the session to retrieve a set of tokens.
> session.login
=> {:csrf=>"BmhxDRW5NAEIx...",
:access=>"eyJhbGciOiJIUzI1NiJ9...",
:access_expires_at=>"..."
:refresh=>"eyJhbGciOiJIUzI1NiJ9...",
:refresh_expires_at=>"..."}
Access/refresh tokens automatically contain expiration time in their payload. Yet expiration times are also added to the output just in case.
The token's payload will be available in the controllers once the access (or refresh) token is authorized.
To perform the refresh do:
> session.refresh(refresh_token)
=> {:csrf=>"+pk2SQrXHRo1iV1x4O...",
:access=>"eyJhbGciOiJIUzI1...",
:access_expires_at=>"..."}
Available JWTSessions::Session.new
options:
- payload: a hash object with session data which will be included into an access token payload. Default is an empty hash.
- refresh_payload: a hash object with session data which will be included into a refresh token payload. Default is the value of the access payload.
-
access_claims: a hash object with JWT claims which will be validated within the access token payload. For example,
JWTSessions::Session.new(payload: { user_id: 1, aud: ['admin'], verify_aud: true })
means that the token can be used only by "admin" audience. Also, the endpoint can automatically validate claims instead. Seetoken_claims
method. - refresh_claims: a hash object with JWT claims which will be validated within the refresh token payload.
- namespace: a string object which helps to group sessions by a custom criteria. For example, sessions can be grouped by user ID, making it possible to logout the user from all devices. More info Sessions Namespace.
- refresh_by_access_allowed: a boolean value. Default is false. It links access and refresh tokens (adds refresh token ID to access payload), making it possible to perform a session refresh by the last expired access token. See Refresh with access token.
- access_exp: an integer value. Contains an access token expiration time in seconds. The value overrides global settings. See Expiration time.
- refresh_exp: an integer value. Contains a refresh token expiration time in seconds. The value overrides global settings. See Expiration time.
Helper methods within Authorization
mixin:
- authorize_access_request!: validates access token within the request.
- authorize_refresh_request!: validates refresh token within the request.
- found_token: a raw token found within the request.
- payload: a decoded token's payload. Returns an empty hash in case the token is absent in the request headers/cookies.
- claimless_payload: a decoded token's payload without claims validation (can be used for checking data of an expired token).
- token_claims: the method should be defined by a developer and is expected to return a hash-like object with claims to be validated within a token's payload.
Rails integration
Include JWTSessions::RailsAuthorization
in your controllers and add JWTSessions::Errors::Unauthorized
exception handling if needed.
class ApplicationController < ActionController::API
include JWTSessions::RailsAuthorization
rescue_from JWTSessions::Errors::Unauthorized, with: :not_authorized
private
def not_authorized
render json: { error: "Not authorized" }, status: :unauthorized
end
end
Specify a signing key for JSON Web Tokens in config/initializers/jwt_session.rb
It is advisable to store the key itself in a secure way, f.e. within app credentials.
JWTSessions.algorithm = "HS256"
JWTSessions.signing_key = Rails.application.credentials.secret_jwt_signing_key
Most of the algorithms require private and public keys to sign a token. However, HMAC requires only a single key and you can use the signing_key
shortcut to sign the token. For other algorithms you must specify private and public keys separately.
JWTSessions.algorithm = "RS256"
JWTSessions.private_key = OpenSSL::PKey::RSA.generate(2048)
JWTSessions.public_key = JWTSessions.private_key.public_key
You can build a login controller to receive access, refresh and CSRF tokens in exchange for the user's login/password.
Refresh controller allows you to get a new access token using the refresh token after access is expired. \
Here is an example of a simple login controller, which returns a set of tokens as a plain JSON response.
It is also possible to set tokens as cookies in the response instead.
class LoginController < ApplicationController
def create
user = User.find_by!(email: params[:email])
if user.authenticate(params[:password])
payload = { user_id: user.id }
session = JWTSessions::Session.new(payload: payload)
render json: session.login
else
render json: "Invalid user", status: :unauthorized
end
end
end
Now you can build a refresh endpoint. To protect the endpoint use the before_action authorize_refresh_request!
.
The endpoint itself should return a renewed access token.
class RefreshController < ApplicationController
before_action :authorize_refresh_request!
def create
session = JWTSessions::Session.new(payload: access_payload)
render json: session.refresh(found_token)
end
def access_payload
# payload here stands for refresh token payload
build_access_payload_based_on_refresh(payload)
end
end
In the above example, found_token
is a token fetched from request headers or cookies. In the context of RefreshController
it is a refresh token.
The refresh request with headers must include X-Refresh-Token
(header name is configurable) with the refresh token.
X-Refresh-Token: eyJhbGciOiJIUzI1NiJ9...
POST /refresh
When there are login and refresh endpoints, you can protect the rest of your secured controllers with before_action :authorize_access_request!
.
class UsersController < ApplicationController
before_action :authorize_access_request!
def index
...
end
def show
...
end
end
Headers must include Authorization: Bearer
with access token.
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
GET /users
The payload
method is available to fetch encoded data from the token.
def current_user
@current_user ||= User.find(payload["user_id"])
end
Methods authorize_refresh_request!
and authorize_access_request!
will always try to fetch the tokens from the headers first and then from the cookies.
For the cases when an endpoint must support only one specific token transport the following authorization methods can be used instead:
authorize_by_access_cookie!
authorize_by_access_header!
authorize_by_refresh_cookie!
authorize_by_refresh_header!
Non-Rails usage
You must include JWTSessions::Authorization
module to your auth class and within it implement the following methods:
- request_headers
def request_headers
# must return hash-like object with request headers
end
- request_cookies
def request_cookies
# must return hash-like object with request cookies
end
- request_method
def request_method
# must return current request verb as a string in upcase, f.e. 'GET', 'HEAD', 'POST', 'PATCH', etc
end
Example Sinatra app.
NOTE: Rack updates HTTP headers by using the HTTP_
prefix, upcasing and underscores for the sake of simplicity. JWTSessions token header names are converted to the rack-style in this example.
require "sinatra/base"
JWTSessions.access_header = "authorization"
JWTSessions.refresh_header = "x_refresh_token"
JWTSessions.csrf_header = "x_csrf_token"
JWTSessions.signing_key = "secret key"
class SimpleApp < Sinatra::Base
include JWTSessions::Authorization
def request_headers
env.inject({}) { |acc, (k,v)| acc[$1.downcase] = v if k =~ /^http_(.*)/i; acc }
end
def request_cookies
request.cookies
end
def request_method
request.request_method
end
before do
content_type "application/json"
end
post "/login" do
access_payload = { key: "access value" }
refresh_payload = { key: "refresh value" }
session = JWTSessions::Session.new(payload: access_payload, refresh_payload: refresh_payload)
session.login.to_json
end
# POST /refresh
# x_refresh_token: ...
post "/refresh" do
authorize_refresh_request!
access_payload = { key: "reloaded access value" }
session = JWTSessions::Session.new(payload: access_payload, refresh_payload: payload)
session.refresh(found_token).to_json
end
# GET /payload
# authorization: Bearer ...
get "/payload" do
authorize_access_request!
payload.to_json
end
# ...
end
Configuration
List of configurable settings with their default values.
Token store
In order to configure a token store you should set up a store adapter in a following way: JWTSessions.token_store = :redis, { redis_url: 'redis://127.0.0.1:6379/0' }
(options can be omitted). Currently supported stores are :redis
and :memory
. Please note, that if you want to use Redis as a store then you should have redis-client
gem listed in your Gemfile. If you do not configure the adapter explicitly, this gem will try to load redis-client
and use it. Otherwise it will fall back to a memory
adapter.
Memory store only accepts a prefix
(used for Redis db keys). Here is a default configuration for Redis:
JWTSessions.token_store = :redis, {
redis_host: "127.0.0.1",
redis_port: "6379",
redis_db_name: "0",
token_prefix: "jwt_",
pool_size: Integer(ENV.fetch("RAILS_MAX_THREADS", 5))
}
On default pool_size
is set to 5. Override it with the value of max number of parallel redis connections in your app.
You can also provide a Redis URL instead:
JWTSessions.token_store = :redis, { redis_url: "redis://localhost:6397" }
NOTE: if REDIS_URL
environment variable is set it is used automatically.
SSL, timeout, reconnect, etc. redis settings are supported:
JWTSessions.token_store = :redis, {
read_timeout: 1.5,
reconnect_attempts: 10,
ssl_params: { verify_mode: OpenSSL::SSL::VERIFY_NONE }
}
If you already have a configured Redis client, you can pass it among the options to reduce opened connections to a Redis server:
JWTSessions.token_store = :redis, {redis_client: redis_pool}
JWT signature
JWTSessions.algorithm = "HS256"
You need to specify a secret to use for HMAC as this setting does not have a default value.
JWTSessions.signing_key = "secret"
If you are using another algorithm like RSA/ECDSA/EDDSA you should specify private and public keys.
JWTSessions.private_key = "abcd"
JWTSessions.public_key = "efjh"
NOTE: ED25519 and HS512256 require rbnacl
installation in order to make it work.
jwt_sessions only uses exp
claim by default when it decodes tokens and you can specify which additional claims to use by
setting jwt_options
. You can also specify leeway to account for clock skew.
JWTSessions.jwt_options[:verify_iss] = true
JWTSessions.jwt_options[:verify_sub] = true
JWTSessions.jwt_options[:verify_iat] = true
JWTSessions.jwt_options[:verify_aud] = true
JWTSessions.jwt_options[:leeway] = 30 # seconds
To pass options like sub
, aud
, iss
, or leeways you should specify a method called token_claims
in your controller.
class UsersController < ApplicationController
before_action :authorize_access_request!
def token_claims
{
aud: ["admin", "staff"],
verify_aud: true, # can be used locally instead of a global setting
exp_leeway: 15 # will be used instead of default leeway only for exp claim
}
end
end
Claims are also supported by JWTSessions::Session
and you can pass access_claims
and refresh_claims
options in the initializer.
Request headers and cookies names
Default request headers/cookies names can be reconfigured.
JWTSessions.access_header = "Authorization"
JWTSessions.access_cookie = "jwt_access"
JWTSessions.refresh_header = "X-Refresh-Token"
JWTSessions.refresh_cookie = "jwt_refresh"
JWTSessions.csrf_header = "X-CSRF-Token"
Expiration time
Access token must have a short life span, while refresh tokens can be stored for a longer time period.
JWTSessions.access_exp_time = 3600 # 1 hour in seconds
JWTSessions.refresh_exp_time = 604800 # 1 week in seconds
It is defined globally, but can be overridden on a session level. See JWTSessions::Session.new
options for more info.
Exceptions
JWTSessions::Errors::Error
- base class, all possible exceptions are inhereted from it.
JWTSessions::Errors::Malconfigured
- some required gem settings are empty, or methods are not implemented.
JWTSessions::Errors::InvalidPayload
- token's payload doesn't contain required keys or they are invalid.
JWTSessions::Errors::Unauthorized
- token can't be decoded or JWT claims are invalid.
JWTSessions::Errors::ClaimsVerification
- JWT claims are invalid (inherited from JWTSessions::Errors::Unauthorized
).
JWTSessions::Errors::Expired
- token is expired (inherited from JWTSessions::Errors::ClaimsVerification
).
CSRF and cookies
When you use cookies as your tokens transport it becomes vulnerable to CSRF. That is why both the login and refresh methods of the Session
class produce CSRF tokens for you. Authorization
mixin expects that this token is sent with all requests except GET and HEAD in a header specified among this gem's settings (X-CSRF-Token
by default). Verification will be done automatically and the Authorization
exception will be raised in case of a mismatch between the token from the header and the one stored in the session.
Although you do not need to mitigate BREACH attacks it is still possible to generate a new masked token with the access token.
session = JWTSessions::Session.new
session.masked_csrf(access_token)
Refresh with access token
Sometimes it is not secure enough to store the refresh tokens in web / JS clients.
This is why you have the option to only use an access token and to not pass the refresh token to the client at all.
Session accepts refresh_by_access_allowed: true
setting, which links the access token to the corresponding refresh token.
Example Rails login controller, which passes an access token token via cookies and renders CSRF:
class LoginController < ApplicationController
def create
user = User.find_by!(email: params[:email])
if user.authenticate(params[:password])
payload = { user_id: user.id }
session = JWTSessions::Session.new(payload: payload, refresh_by_access_allowed: true)
tokens = session.login
response.set_cookie(JWTSessions.access_cookie,
value: tokens[:access],
httponly: true,
secure: Rails.env.production?)
render json: { csrf: tokens[:csrf] }
else
render json: "Invalid email or password", status: :unauthorized
end
end
end
The gem provides the ability to refresh the session by access token.
session = JWTSessions::Session.new(payload: payload, refresh_by_access_allowed: true)
tokens = session.refresh_by_access_payload
In case of token forgery and successful refresh performed by an attacker the original user will have to logout.
To protect the endpoint use the before_action authorize_refresh_by_access_request!
.
Refresh should be performed once the access token is already expired and we need to use the claimless_payload
method in order to skip JWT expiration validation (and other claims) in order to proceed.
Optionally refresh_by_access_payload
accepts a block argument (the same way refresh
method does).
The block will be called if the refresh action is performed before the access token is expired.
Thereby it's possible to prohibit users from making refresh calls while their access token is still active.
tokens = session.refresh_by_access_payload do
# here goes malicious activity alert
raise JWTSessions::Errors::Unauthorized, "Refresh action is performed before the expiration of the access token."
end
Example Rails refresh by access controller with cookies as token transport:
class RefreshController < ApplicationController
before_action :authorize_refresh_by_access_request!
def create
session = JWTSessions::Session.new(payload: claimless_payload, refresh_by_access_allowed: true)
tokens = session.refresh_by_access_payload
response.set_cookie(JWTSessions.access_cookie,
value: tokens[:access],
httponly: true,
secure: Rails.env.production?)
render json: { csrf: tokens[:csrf] }
end
end
For the cases when an endpoint must support only one specific token transport the following auth methods can be used instead:
authorize_refresh_by_access_cookie!
authorize_refresh_by_access_header!
Refresh token hijack protection
There is a security recommendation regarding the usage of refresh tokens: only perform refresh when an access token expires.
Sessions are always defined by a pair of tokens and there cannot be multiple access tokens for a single refresh token. Simultaneous usage of the refresh token by multiple users can be easily noticed as refresh will be performed before the expiration of the access token by one of the users. As a result, refresh
method of the Session
class supports an optional block as one of its arguments which will be executed only in case of refresh being performed before the expiration of the access token.
session = JwtSessions::Session.new(payload: payload)
session.refresh(refresh_token) { |refresh_token_uid, access_token_expiration| ... }
Flush Sessions
Flush a session by its refresh token. The method returns number of flushed sessions:
session = JWTSessions::Session.new
tokens = session.login
session.flush_by_token(tokens[:refresh]) # => 1
Flush a session by its access token:
session = JWTSessions::Session.new(refresh_by_access_allowed: true)
tokens = session.login
session.flush_by_access_payload
# or
session = JWTSessions::Session.new(refresh_by_access_allowed: true, payload: payload)
session.flush_by_access_payload
Or by refresh token UID:
session.flush_by_uid(uid) # => 1
Sessions namespace
It's possible to group sessions by custom namespaces:
session = JWTSessions::Session.new(namespace: "account-1")
Selectively flush sessions by namespace:
session = JWTSessions::Session.new(namespace: "ie-sessions")
session.flush_namespaced # will flush all sessions which belong to the same namespace
Selectively flush one single session inside a namespace by its access token:
session = JWTSessions::Session.new(namespace: "ie-sessions", payload: payload)
session.flush_by_access_payload # will flush a specific session which belongs to an existing namespace
Flush access tokens only:
session = JWTSessions::Session.new(namespace: "ie-sessions")
session.flush_namespaced_access_tokens # will flush all access tokens which belong to the same namespace, but will keep refresh tokens
Force flush of all app sessions:
JWTSessions::Session.flush_all
Logout
To logout you need to remove both access and refresh tokens from the store.
Flush sessions methods can be used to perform logout.
Refresh token or refresh token UID is required to flush a session.
To logout with an access token, refresh_by_access_allowed
should be set to true on access token creation. If logout by access token is allowed it is recommended to ignore the expiration claim and to allow to logout with the expired access token.
Examples
You can use a mixed approach for the cases when you would like to store an access token in localStorage and refresh token in HTTP-only secure cookies.
Rails controllers setup example:
class LoginController < ApplicationController
def create
user = User.find_by(email: params[:email])
if user&.authenticate(params[:password])
payload = { user_id: user.id, role: user.role, permissions: user.permissions }
refresh_payload = { user_id: user.id }
session = JWTSessions::Session.new(payload: payload, refresh_payload: refresh_payload)
tokens = session.login
response.set_cookie(JWTSessions.refresh_cookie,
value: tokens[:refresh],
httponly: true,
secure: Rails.env.production?)
render json: { access: tokens[:access], csrf: tokens[:csrf] }
else
render json: "Cannot login", status: :unauthorized
end
end
end
class RefreshController < ApplicationController
before_action :authorize_refresh_request!
def create
tokens = JWTSessions::Session.new(payload: access_payload).refresh(found_token)
render json: { access: tokens[:access], csrf: tokens[:csrf] }
end
def access_payload
user = User.find_by!(email: payload["user_id"])
{ user_id: user.id, role: user.role, permissions: user.permissions }
end
end
class ResourcesController < ApplicationController
before_action :authorize_access_request!
before_action :validate_role_and_permissions_from_payload
# ...
end
Contributing
Fork & Pull Request.
RbNaCl and sodium cryptographic library are required for tests.
For MacOS see these instructions.
For example, with Homebrew:
brew install libsodium
License
MIT