Service Identity Propagation Using Clone OAuth Clients
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In networked computing environments, especially multi-tenant cloud-computing settings, conventional authentication methods for reusable services are inadequate, leading to security concerns, large token sizes causing data storage and network bandwidth issues, separation of scopes within tokens being cumbersome, and inefficient token lifecycle management.
Innovation Solution
Implementing Open Authorization (OAUTH) authentication using JavaScript Object Notation (JSON) Web Tokens (JWTs) with a Master OAUTH Client and clone/copy clients, where each Service instance has a specific token associated with a User, reducing token scope and size, and simplifying token management by creating new Service instances for new Applications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional authentication methods are used for reusable services, then service accessibility is maintained, but system security deteriorates
Solution Approach 1:
The patent creates a clone OAUTH Client for each Service instance, which is a copy of the Master OAUTH Client. This clone contains service-specific information and enables secure authentication for that particular service instance. The copying principle allows each service to have its own authentication credentials while maintaining a unified master client structure, thus improving security without excessive complexity.
Solution Approach 2:
The authentication system is segmented into a Master OAUTH Client and multiple clone OAUTH Clients, one for each Service instance. Each clone is independent and service-specific, allowing fine-grained security control. This segmentation enables the system to maintain high security by isolating service credentials while keeping the overall architecture manageable through the master-client relationship.
2Adaptability or versatility
If tokens contain information for all Services a user has access to, then comprehensive service access is enabled, but data storage space and network bandwidth requirements increase
Solution Approach 1:
Instead of including all service information in a single large token, the system creates a separate clone OAUTH Client for each service instance. Each clone contains only the necessary service-specific information. When a user accesses a service, only the relevant clone is used, resulting in smaller, more efficient tokens that reduce data storage and network bandwidth requirements while maintaining comprehensive service access capability.
3Ease of operation
If a single Token is used for multiple Services, then token management is simplified, but third-party Services can maliciously leverage user information to access other Services
Solution Approach 1:
The patent segments the authentication system into service-specific clone OAUTH Clients, each with its own scope. This segmentation ensures that a token issued for one service cannot be used to access other services, preventing security vulnerabilities. The token scope is limited to the specific service it was issued for, while the overall system maintains ease of operation through the master-client relationship that manages all clones centrally.
4Adaptability or versatility
If comprehensive scope information is included in Tokens, then all service access rights are granted, but token size increases and processing speed decreases
Solution Approach 1:
The system creates separate clone OAUTH Clients for each service, each containing only the necessary scope information for that service. When a token is issued, it only includes the scope information relevant to the specific service being accessed. This approach maintains comprehensive service access rights across all services while keeping individual token sizes small, thereby improving processing speed and reducing computational overhead.
Data Source
AI summary
A request from a User for a Service is received by an Application. An Open Authorization (OAUTH) Client of the Service is requested from a Service Instance of the Service. A copy OAUTH Client of the Service specific to the User is provided based on a clone OAUTH Client associated with the Service Instance. A Token is obtained to access the Service by providing the copy OAUTH Client to a User Account and Authorization (UAA) entity. Access to the Service is obtained by providing the Token.