Server-Controlled Authorization Proof of Possession
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing web security systems face challenges in verifying the authenticity of authorization tokens, allowing unauthorized access due to the separation of authentication and authorization sub-systems and reliance on client-side trustworthiness, which makes them vulnerable to cloning attacks and pirate access.
Innovation Solution
An end-to-end system with a security headend on the server side and a security engine on the client side, where the server provisions keys and a secure time base for client devices, enabling the client to generate and present authorization proof tokens that can be verified by servers, ensuring the legitimacy of token possession.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the system uses separate authentication and authorization sub-systems, then the system can support different business entities for authentication and content delivery, but the authorization sub-system cannot verify the authenticity of tokens, allowing unauthorized access
Solution Approach 1:
The patent introduces a cryptographic binding mechanism as an intermediary between the authentication and authorization sub-systems. The authorization token is cryptographically bound to the client's private key, creating a verifiable link that allows the authorization sub-system to verify token authenticity without direct access to authentication credentials. This resolves the contradiction by enabling security verification while maintaining system separation.
Solution Approach 2:
The patent segments the authentication proof into two parts: the authorization token issued by the authentication sub-system and the cryptographic proof of possession verified by the authorization sub-system. This segmentation allows each sub-system to perform its function independently while ensuring overall security through the cryptographic binding between the token and client key.
2Reliability
If the system performs frequent authorizations to protect against unauthorized access, then security is improved, but user experience deteriorates due to repeated authentication requirements
Solution Approach 1:
The patent performs authentication preliminarily by issuing an authorization token that binds the client's identity to their cryptographic key. This preliminary authentication allows the authorization sub-system to verify subsequent requests without requiring repeated full authentication, thus maintaining security while improving user convenience.
Solution Approach 2:
The system implements feedback through the cryptographic proof of possession mechanism, where each authorization request includes verification that the client possesses the correct private key. This continuous feedback ensures security without requiring repeated human authentication, as the cryptographic verification happens automatically with each request.
3Device complexity
If the system relies on client-side trustworthiness for token validation, then the authorization process is simplified, but the system becomes vulnerable to cloning attacks and pirate access
Solution Approach 1:
The patent replaces the mechanical/trust-based verification system with a cryptographic verification system. Instead of relying on client-side trustworthiness, the system uses mathematical cryptography to verify that the client possesses the correct private key through the proof of possession mechanism, thereby protecting against cloning attacks while maintaining reasonable process complexity.
Data Source
AI summary
Techniques for server control of client authorization proof of possession are described herein. In various embodiments, a first server provisions client authorization proof of possession for a client device a real-world time, a client public key, and a client private key. The first server generates provisioning response message(s) including the client public key, the client private key, the real-world time, and/or an assertion object, and sends the message(s) to the client device. In various embodiments, a client device obtains an authorization proof token generated based on a client public key, a client private key, and a real-world time provisioned by a first server. The client device generates a request and sends the request to a second server, the request includes the authorization proof token and an assertion object from the first server signed by a server private key and an expiration time and a reference to the client public key.