2019-05-18 11:30:16 +00:00
|
|
|
---
|
|
|
|
layout: default
|
|
|
|
title: Sessions
|
|
|
|
permalink: /configuration
|
|
|
|
parent: Configuration
|
|
|
|
nav_order: 3
|
|
|
|
---
|
|
|
|
|
|
|
|
## Sessions
|
|
|
|
|
|
|
|
Sessions allow a user's authentication to be tracked between multiple HTTP
|
|
|
|
requests to a service.
|
|
|
|
|
|
|
|
The OAuth2 Proxy uses a Cookie to track user sessions and will store the session
|
|
|
|
data in one of the available session storage backends.
|
|
|
|
|
|
|
|
At present the available backends are (as passed to `--session-store-type`):
|
2019-05-28 13:26:22 +00:00
|
|
|
- [cookie](cookie-storage) (default)
|
2019-05-18 11:30:16 +00:00
|
|
|
|
|
|
|
### Cookie Storage
|
|
|
|
|
|
|
|
The Cookie storage backend is the default backend implementation and has
|
|
|
|
been used in the OAuth2 Proxy historically.
|
|
|
|
|
|
|
|
With the Cookie storage backend, all session information is stored in client
|
|
|
|
side cookies and transferred with each and every request.
|
|
|
|
|
|
|
|
The following should be known when using this implementation:
|
|
|
|
- Since all state is stored client side, this storage backend means that the OAuth2 Proxy is completely stateless
|
|
|
|
- Cookies are signed server side to prevent modification client-side
|
|
|
|
- It is recommended to set a `cookie-secret` which will ensure data is encrypted within the cookie data.
|
|
|
|
- Since multiple requests can be made concurrently to the OAuth2 Proxy, this session implementation
|
|
|
|
cannot lock sessions and while updating and refreshing sessions, there can be conflicts which force
|
|
|
|
users to re-authenticate
|