Secure Token Refresh Using Asymmetric Key Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The OAuth 2.0 standard's refresh tokens are vulnerable to man-in-the-middle attacks and server-side data compromise due to their transmission over open channels and storage as shared secrets.
Innovation Solution
Implementing a secure token refresh method using asymmetric cryptography, where clients generate a key pair and send the public key to the authentication service, which verifies signed proof data using the public key to issue new access tokens, and can revoke access by deleting the public key, thereby preventing unauthorized access.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If refresh tokens are transmitted over open communication channels to the authorization server, then token refresh functionality is enabled, but the system becomes vulnerable to man-in-the-middle attacks
Solution Approach 1:
The patent introduces public key infrastructure as an intermediary mechanism. Instead of directly transmitting refresh tokens over open channels, the system uses public keys to sign and verify token requests. The public key acts as a mediator that enables secure communication without requiring direct trusted channels, allowing the refresh token to be protected through cryptographic verification rather than relying solely on channel security.
Solution Approach 2:
The patent replaces the mechanical security approach (relying on secure transport protocols and channel protection) with a cryptographic verification system. Instead of depending on the security of the communication channel itself, the system substitutes a verification mechanism using digital signatures. The authorization server verifies the refresh token's authenticity through cryptographic validation rather than trusting the transport layer, fundamentally changing how security is achieved.
2Reliability
If refresh tokens are stored on the server side for validation as shared secrets, then token verification is enabled, but the system becomes prone to server-side data compromise
Solution Approach 1:
The patent extracts the critical verification information (public key) from the server-side stored data and places it on the client side. Instead of storing only minimal token data on the server, the system extracts and distributes the public key to clients, enabling them to perform local verification. This extraction reduces the value of server-side data, as compromising server storage no longer provides attackers with the ability to forge tokens without the private key.
Solution Approach 2:
The patent inverts the traditional authentication model where the server holds all verification power. Instead, the client is empowered with the public key to independently verify token authenticity. The server's role changes from actively validating each token against stored secrets to passively accepting tokens that can be verified by anyone with the public key. This inversion distributes verification capability and reduces server-side security risks.
3Reliability
If asymmetric cryptography is implemented with key pairs, then security against attacks is improved, but device complexity increases
Solution Approach 1:
The patent performs key pair generation as a preliminary action during the initial authentication process, before the refresh token mechanism is needed. By establishing the public key early in the authentication flow, the system avoids the complexity of dynamic key management during token refresh operations. The public key is generated, exchanged, and stored upfront, allowing subsequent token refreshes to use this pre-established cryptographic foundation without additional key management overhead.
Data Source
AI summary
Technologies are shown for secure token refresh where a client receives a first access token from an authentication service, generates an asymmetric key pair, stores the first access token in association with a private key, and sends a public key to the authentication service. The service stores the public key in association with the first access token. The client sends a refresh token request to the service with the first access token. The service responds with a verification request with proof data. The client signs the proof data with the private key and sends the signed proof data to the service. The service verifies the signed proof data using the public key associated with the first access token, creates a second access token that is stored in association with the public key, and sends the second access token to the client, which stores it in association with the private key.