Access Token Handle Architecture for Session-Based Key Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing cryptographic key management systems expose decryption keys to clients, leading to potential unauthorized access and user tracking, as they are often long-lived, shared among multiple systems, and stored outside secure networks.
Innovation Solution
An authorization server generates ephemeral, time-bound encryption keys per user session, embedding them into access tokens and providing token handles to clients, ensuring keys are only shared within secure networks and not stored on client devices, using refresh tokens for key computation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If decryption keys are stored or exposed to the client, then key management is simplified, but security is compromised as keys become accessible to attackers
Solution Approach 1:
The patent extracts the decryption key from the client environment and places it inside the access token, which is then handed to a third-party service. This ensures the key never resides on the client device, eliminating the risk of key exposure to attackers while maintaining simplified key management through automatic key generation and rotation.
Solution Approach 2:
The access token serves as an intermediary carrier that contains the decryption key. Instead of directly exposing the key to the client or storing it on client devices, the system uses the access token as a secure intermediary mechanism to transmit and manage the key temporarily during the session.
2Adaptability or versatility
If keys are long-lived and shared among multiple systems, then system interoperability is improved, but user tracking and unauthorized decryption become possible
Solution Approach 1:
The patent segments the key into multiple parts: a static access token handle that identifies the user session, and a dynamic encryption key that is generated fresh for each API call. This segmentation allows the system to maintain interoperability through the persistent token handle while ensuring security through ephemeral, non-shareable encryption keys that cannot be tracked or reused.
Solution Approach 2:
The encryption key transitions from being static and long-lived to being dynamic and ephemeral. Each API call generates a new encryption key that is automatically rotated, making the key lifecycle adaptive to the current session rather than fixed. This dynamic approach prevents user tracking while maintaining system interoperability through the persistent access token handle.
3Ease of operation
If encryption keys are shared among multiple systems, then key management is simplified, but the risk of unauthorized access increases
Solution Approach 1:
The patent removes the encryption key from the client environment entirely and embeds it within the access token that is transmitted to the third-party service. This extraction ensures the key is never stored on client devices or shared among multiple systems, eliminating unauthorized access risks while maintaining ease of operation through automatic key generation and management.
Solution Approach 2:
The encryption key is designed as a disposable, ephemeral object that is generated fresh for each API call and automatically rotated. Instead of being a valuable, long-lived asset that needs careful sharing and management, the key is treated as a temporary credential that is discarded after use, simplifying key management while eliminating the risk of unauthorized access.
Data Source
AI summary
An authorization server, method, and non-transitory computer readable medium for generating and managing at least one access token associated with a client. The authorization server may include a memory configured to store computer readable instructions; and processing circuitry configured to execute the computer readable instructions to cause the authorization server to map, within a database, at least one access token to an access token handle associated with a client, return the access token handle to the client, and selectively provide the access token to at least one web Application Programming Interface (API) in response to receipt of the access token handle from the at least one web API.