Resource-Centric Authorization in Multi-Partner Microservice Ecosystems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional authorization methods in microservice-based systems, such as OAuth, are not suitable for fine-grained policy-based or role-based authorization, leading to difficulties in managing permissions across multiple microservices in a multi-partner ecosystem.
Innovation Solution
A resource-centric authorization system that uses a lookup table to determine access based on client IDs, allowing granular control over resources such as creating, revising, or checking the status of applications, and utilizes OAuth tokens generated by an OAuth server to authenticate and authorize access to microservices like application, offer, and vehicle pricing services.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If traditional OAuth authorization methods are used in microservice-based systems, then authentication can be achieved, but fine-grained policy-based or role-based authorization cannot be implemented effectively
Solution Approach 1:
The patent segments the authorization system into multiple independent components: OAuth token authentication layer, client ID extraction layer, resource identifier parsing layer, and permission checking layer. This segmentation allows traditional OAuth to be combined with fine-grained resource-based access control, resolving the contradiction between using standard OAuth and achieving fine-grained authorization.
Solution Approach 2:
The patent introduces an intermediary authorization checking mechanism that sits between the OAuth authentication process and the microservice resource access. This intermediary layer extracts client IDs from tokens, parses resource identifiers from URLs, and performs policy-based access control decisions, enabling fine-grained authorization while maintaining OAuth compatibility.
2Reliability
If fine-grained permission management is implemented across multiple microservices, then security is improved, but system complexity increases
Solution Approach 1:
The patent implements a universal authorization checking mechanism that can be applied across all microservices in the ecosystem. The same token validation, client ID extraction, resource parsing, and permission checking logic is reused across different services (application microservice, offer microservice, vehicle pricing microservice), reducing overall system complexity while maintaining fine-grained security control.
Solution Approach 2:
The patent changes the parameter representation from traditional role-based identifiers to resource-based identifiers (resource IDs in URLs). This parameter change enables a unified approach to access control where permissions are defined in terms of resource access rather than complex role hierarchies, simplifying the authorization system while improving security.
3Reliability
If OAuth tokens are used for authentication, then user account security is maintained, but delegated authorization is not suitable for fine-grained policy-based authorization
Solution Approach 1:
The patent performs preliminary actions by extracting the client ID from the OAuth token early in the request processing cycle, before the actual resource access occurs. It also pre-parses the resource identifier from the URL and pre-evaluates the access policy. This preliminary processing simplifies subsequent authorization checks and makes fine-grained policy-based authorization easier to manage while maintaining authentication security.
Data Source
AI summary
An exemplary system, method and computer accessible medium can include receiving an authorization token related to a customer(s), determining a client identification (ID) associated with the customer(s) based on the authorization token, and determining access to a microservices(s) based on the client ID. An application for a loan(s) from the customer (s) can be received based on the client ID and the loan(s) can be associated with an application ID(s). A further authorization token related to a further customer(s) can be received, a further client ID can be determined based on the further authorization token, a determination can be made as to whether the further client ID has access to the application, and access to the application can be granted to the further customer(s) if the further client ID is determined to have access to the application.