Rule-Enhanced Access Token for Local Authorization Enforcement
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing cloud-based identity servers do not effectively enforce access rules when generating access tokens, leading to the need for client applications to make frequent backchannel requests to the identity server for authorization, which is inefficient and resource-intensive.
Innovation Solution
Generating a rule-enhanced access token that includes constraints for granting or denying access, allowing the token receiving entity to enforce access rules without constant communication with the identity server, by embedding rule information directly within the access token or using refresh tokens to update rules.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If access rules are enforced through backchannel requests to the identity server, then authorization accuracy is improved, but system efficiency deteriorates due to frequent communication overhead
Solution Approach 1:
The patent embeds access rules and constraints directly into the access token during the initial authorization process. This preliminary action allows the resource server to enforce rules locally without requiring backchannel requests, thereby maintaining authorization accuracy while eliminating communication overhead during resource access operations.
Solution Approach 2:
The patent creates a copy of the authorization rules and constraints from the identity server and embeds them within the access token. This copying mechanism enables the resource server to have a local copy of the rules for enforcement, reducing the need for continuous communication with the identity server while ensuring rule compliance.
2Productivity
If access rules are embedded in the access token, then system efficiency is improved by eliminating backchannel requests, but device complexity increases due to token structure modifications
Solution Approach 1:
The patent extends the existing access token structure to serve multiple functions: authentication verification, authorization rule enforcement, and constraint validation. By making the token multi-functional, the system achieves improved efficiency without requiring separate authorization tokens or structures, thus limiting the increase in complexity.
Solution Approach 2:
The patent modifies the access token by adding specific parameters such as constraints and rules embedded within the token structure. These parameter changes enable local rule enforcement while maintaining compatibility with existing OAuth 2.0 workflows, balancing the need for enhanced functionality with minimal disruption to the existing system architecture.
3Ease of operation
If OAuth 2.0 protocol is used for authorization, then ease of operation is improved, but authorization enforcement capability deteriorates due to lack of rule support
Solution Approach 1:
The patent performs preliminary embedding of access rules and constraints into the access token during the OAuth 2.0 authorization process. This allows the standard OAuth flow to remain simple and easy to operate, while the embedded rules provide the necessary enforcement capability that the base protocol lacks.
Solution Approach 2:
The patent copies authorization rules from the identity server's policy database and embeds them in the access token. This copying mechanism preserves the simplicity of the OAuth 2.0 protocol while adding rule enforcement capability, as the rules are transferred rather than requiring a complete protocol redesign.
Data Source
AI summary
Techniques for described for generating and using rule-enhanced access tokens in connection with authorization for access to resources. An access token is generated in response to determining that a user is authorized to access a protected resource. The access token contains rule information including one or more constraints, each constraint corresponding to a condition for granting or denying access to the protected resource. Upon receiving the access token, a client application can present the access token for accessing the protected resource. The client application can be configured to enforce one or more rules represented in the rule information. The client application can, for example, determine based on the one or more constraints that a condition for granting access is unmet and, in response, cancel a pending access request for the protected resource.