Token Revocation Policy for DoS Protection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current token revocation methods in web applications face scaling limitations and are prone to denial-of-service (DoS) attacks, as they require extensive processing to validate and revoke tokens, leading to system overload when multiple tokens need to be revoked simultaneously.

Innovation Solution

Implementing a token revocation policy that progressively revokes subsets of tokens over time, using a set of rules to manage the revocation process, thereby avoiding simultaneous token validation and reducing the load on the token authority server.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If tokens are revoked simultaneously in bulk, then token revocation completeness is improved, but system load and risk of DoS attacks increase

Engineering Contradiction:
Improvetoken revocation completenessVSAvoidsystem overload and DoS attacks
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent segments the bulk token revocation process into smaller batches processed at different time intervals. Instead of revoking all tokens simultaneously, the system divides them into groups and processes each group sequentially, reducing the peak load on the token authority server while ensuring complete revocation of all unauthorized tokens.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements dynamic batch size adjustment based on system conditions. The batch processing parameters are made adaptive, allowing the system to adjust the number of tokens revoked per batch and the time intervals between batches based on server load, network conditions, and urgency of revocation, thereby optimizing between completeness and system protection.

Inventive Principle:
Principle #15Dynamics

2Reliability

If extensive processing is performed to validate and revoke tokens, then token security is improved, but processing time and system resources increase

Engineering Contradiction:
Improvetoken securityVSAvoidprocessing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent performs preliminary actions by pre-identifying tokens that need revocation before the actual revocation process. The system prepares the revocation list and organizes tokens into batches in advance, so that when revocation begins, the processing can proceed efficiently without extensive real-time validation overhead, reducing overall processing time while maintaining security.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If all tokens are revoked at once, then revocation efficiency is improved, but service disruption and system instability increase

Engineering Contradiction:
Improverevocation efficiencyVSAvoidservice stability
Core Design Contradiction:
ProductivityVSStability of the object's composition

Solution Approach 1:

The patent implements periodic action by scheduling token revocation in regular time intervals rather than all at once. The system establishes a rhythm of revoking batches of tokens at predetermined intervals, which maintains steady system operation and prevents sudden service disruptions while still achieving complete revocation efficiently over time.

Inventive Principle:
Principle #19Periodic action

Data Source

PatentUS10038723B2Method and apparatus for reliable token revocation
Publication Date: 2018.07.31 MK SYST USA INC
  • US10038723B2 patent drawing
  • US10038723B2 patent drawing
  • US10038723B2 patent drawing

AI summary

Methods and systems for reliable token revocation at a server are described. The server receives, a token revocation policy, which includes an identification of a set of users for which a set of associated tokens are to be revoked. The server receives, from a first client device, a first request to access resources at the server, the first request including a first token generated at the token authority server for the client device, wherein the first token is associated with a first expiration time interval; and denies access to the resources at the server based on the first token and the token revocation policy, prior to an expiration of the first expiration time interval associated with the first token.