35 lines
		
	
	
		
			1.3 KiB
		
	
	
	
		
			Markdown
		
	
	
	
			
		
		
	
	
			35 lines
		
	
	
		
			1.3 KiB
		
	
	
	
		
			Markdown
		
	
	
	
| ---
 | |
| 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`):
 | |
| - [cookie](cookie-storage) (deafult)
 | |
| 
 | |
| ### 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
 |