Third-Party Session Token Management via DNS Encryption
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Managing session tokens for API servers is burdensome, particularly when multiple valid tokens exist due to frequent client interactions, leading to performance issues and security risks, especially in IoT devices that lack robust security mechanisms for storing API credentials.
Innovation Solution
Implementing a credential escrow management service where API credentials are stored on a third-party server, which generates and manages session tokens, encrypting them with the client device's public key and distributing them through a DNS record for secure retrieval by the client.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a new session token is issued every time a client-side integration interacts with the API server, then the device can authenticate with the API server, but multiple valid session tokens may exist at the same time causing performance issues and unnecessary loads on the authentication component
Solution Approach 1:
The patent implements token pre-rotation where a new session token is generated and stored on the server before the current token expires. The client is notified to switch to the new token before the old one becomes invalid, preventing overlap of multiple valid tokens and reducing authentication server load.
Solution Approach 2:
The patent makes the session token lifecycle dynamic by implementing automated token rotation with expiration tracking. The system dynamically manages token validity periods, automatically invalidating old tokens and activating new ones based on expiration timestamps, rather than using static token issuance.
2Reliability
If session tokens are managed by the API server, then authentication can be established, but the API server bears the burden of managing multiple valid tokens which increases complexity
Solution Approach 1:
The patent segments the token management responsibilities by separating token generation, storage, and validation functions. The API server generates tokens but stores them in a dedicated token storage mechanism with expiration tracking, while the client handles token selection and validation, distributing the management burden.
Solution Approach 2:
The patent introduces a token management layer that acts as an intermediary between the API server and clients. This layer handles token issuance, expiration tracking, and validation logic, shielding the API server from direct token management complexity while maintaining authentication reliability.
3Ease of operation
If API credentials are stored in IoT devices, then the devices can authenticate with the API server, but IoT devices lack robust security mechanisms making credential storage insecure
Solution Approach 1:
The patent extracts sensitive API credentials from IoT devices and stores them securely on the API server instead. The server stores credential-hash pairs where the hash is derived from the device identifier, allowing authentication without exposing actual credentials in the device. Only necessary token information is transmitted to devices.
Solution Approach 2:
The patent creates a secure copy mechanism where the server stores a hash copy of the device credential rather than the original. This hash copy is used for verification purposes, allowing the server to authenticate devices without storing or transmitting sensitive credential information, thereby maintaining security while enabling authentication.
Data Source
Figure 1
Figure 2~3
Figure 4
AI summary
Embodiments relate to a system that may include a third-party server and a domain name system (DNS). The third-party server may be configured to receive a request for a session token from a named entity device for the named entity device to communicate with an application programming interface (API). The API may be associated with a domain. The third-party server may obtain the session token from the API. The third-party server may encrypt the session token with a public key corresponding to the named entity device to generate an encrypted session token. The DNS may be configured to receive the encrypted session token and publish a DNS record at a namespace of the DNS, the DNS record containing the encrypted session token for the named entity device to retrieve the session token. The named entity device may decrypt the encrypted session token by the private key stored at the device.