Centralized Authentication Policy Server for Secure Token Issuance
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current token-based access control systems lack the capability for single website login across multiple sites with central control and are not secure when used through untrusted mobile applications, as they do not effectively manage user credentials.
Innovation Solution
A method combining centralized cookie-based authentication with token-based authorization, where user credentials are intercepted and processed by a policy server, and a token is issued to allow secure access to protected resources without sharing credentials with the mobile application, using HTTP header variables to authenticate and authorize user requests.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If token-based access control is used, then access control functionality is provided, but user credentials are exposed to untrusted mobile applications
Solution Approach 1:
The patent introduces a server as an intermediary between the mobile application and the authentication system. The server receives credentials from the application, authenticates them centrally, and returns only a token without exposing the actual credentials. This mediator architecture prevents credential exposure while maintaining access control functionality.
Solution Approach 2:
The patent extracts the sensitive credential verification process from the mobile application and relocates it to a centralized server. The application only handles token transmission, while the server performs the actual credential authentication. This separation removes credentials from the untrusted application environment.
2Adaptability or versatility
If centralized authentication is implemented, then single login capability is achieved, but system complexity increases
Solution Approach 1:
The patent creates a universal authentication server that handles multiple authentication types (token-based, credential-based) and serves multiple applications through a single centralized system. This multi-functional approach enables single login capability across different services without requiring separate authentication systems for each.
3Ease of operation
If mobile applications handle user credentials directly, then authentication can be performed, but security is compromised
Solution Approach 1:
The server acts as an intermediary that receives credentials from the mobile application, performs authentication centrally, and returns authentication results without exposing credentials to the application. This maintains authentication capability while securing credentials through the intermediary layer.
4Productivity
If token credentials are issued to mobile applications, then access to protected resources is enabled, but credentials may be intercepted or misused
Solution Approach 1:
The patent changes the parameter of credential transmission by using HTTP header variables instead of traditional token parameters in URLs or request bodies. This parameter change makes credential interception more difficult while maintaining access efficiency through standardized header transmission.
Data Source
Figure 1a~1b
Figure 2a
Figure 2b
AI summary
User access to a protected resource is controlled by: intercepting a request from a client browser (80) directed to a server (50); requesting user credentials from the client browser (80); processing user credentials received from the client browser (80) to authenticate the user (20); redirecting the client browser (80) to an authorization server (70) configured to issue a token credential; intercepting an authorization request from the browser (80) to the authorization server (70), and inserting into the authorization request an HTTP header variable indicating the authentication status of the user (20). The authorization server (70) is arranged to issue a token credential, which may be used by the user (20) to obtain a token for indicating to a server (50) hosting the protected resource authorization of the user (20) to access the protected resource.