Limited-Scope Access Token Generation for API Security

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The use of master access tokens in API communication can lead to security risks as they grant unauthorized access to multiple resources if compromised, and existing solutions require intermediary components and frequent token exchanges, introducing security, cost, and scaling concerns.

Innovation Solution

Generating multiple limited-scope access tokens that are specific to each resource and embedding them into a main access token or storing them separately, allowing for secure and efficient access to individual resources without the need for intermediary components or frequent token exchanges.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a master access token is used to access multiple resources, then ease of operation is improved, but security is worsened due to unauthorized access risks

Engineering Contradiction:
Improveease of operationVSAvoidsecurity
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent segments a single master access token into multiple child access tokens, each with specific scope limitations for different resources. The authorization service generates child tokens that inherit permissions from the parent token but are restricted to specific resource sets, allowing operational simplicity while enhancing security through granular access control.

Inventive Principle:
Principle #1Segmentation

2Reliability

If frequent token exchanges are implemented to maintain security, then security is improved, but productivity is worsened due to additional overhead

Engineering Contradiction:
ImprovesecurityVSAvoidproductivity
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent implements preliminary action by pre-generating multiple child access tokens with different scope limitations before they are needed. These tokens are stored and ready for use, eliminating the need for frequent real-time token exchanges while maintaining security. The system proactively prepares secured access credentials in advance.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If intermediary components are added to manage token security, then security is improved, but device complexity is worsened

Engineering Contradiction:
ImprovesecurityVSAvoiddevice complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements self-service by enabling the authorization service to automatically generate, manage, and revoke child access tokens without requiring external intermediary components. The system autonomously handles token lifecycle management, including generating tokens with appropriate scopes, storing them securely, and revoking them when no longer needed, thereby reducing system complexity.

Inventive Principle:
Principle #25Self-service

4Reliability

If multiple specialized tokens are generated for each resource, then security is improved, but ease of operation is worsened due to increased complexity

Engineering Contradiction:
ImprovesecurityVSAvoidease of operation
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent implements universality by creating a parent-child token relationship where a single parent access token can generate multiple child tokens for different resources. The authorization service provides a universal interface that automatically manages the creation and distribution of scope-specific child tokens, maintaining ease of operation while enabling fine-grained security control across multiple resources.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS20230300135A1Generation of multiple limited-scope access tokens
Publication Date: 2023.09.21 CITRIX SYSTEMS INC
  • US20230300135A1 patent drawing
  • US20230300135A1 patent drawing
  • US20230300135A1 patent drawing

AI summary

In some disclosed embodiments, a first computing system may receive a message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner. In response to the message, the first computing system may generate both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource.