Reverse Proxy Certificate to OAuth Token Conversion

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

There is an incompatibility between certificate-based authentication mechanisms used by client systems and token-based authentication/authorization services in cloud environments, preventing certificate-based clients from accessing services that rely on token-based authentication/authorization.

Innovation Solution

A system that enables certificate-based clients to access token-based services by initiating TLS mutual authentication, where a reverse proxy generates an authentication token based on the client's X.509 certificate, which is then converted into a JSON Web Token (JWT) and used to obtain an OAuth token for authorization, allowing access to cloud services.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a cloud service uses token-based authentication/authorization (OAuth), then authorization management and security are improved, but compatibility with certificate-based clients is lost

Engineering Contradiction:
Improveauthorization managementVSAvoidcompatibility with certificate-based clients
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary component that performs certificate validation and token generation. This intermediary acts as a bridge between certificate-based clients and token-based services, accepting X.509 certificates from clients, validating them against trusted certificate authorities, and generating appropriate OAuth tokens (such as JWTs or opaque tokens) that the service can use for authorization. This resolves the contradiction by maintaining the secure token-based authorization system while adding compatibility layer for certificate-based clients.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If a client system uses certificate-based authentication, then authentication security is improved, but ability to access token-based services is lost

Engineering Contradiction:
Improveauthentication securityVSAvoidaccess to token-based services
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The intermediary automatically performs the certificate-to-token conversion process, so certificate-based clients can access token-based services without manual intervention. The client simply presents its X.509 certificate, and the intermediary handles the validation and token generation transparently, making the process as easy as traditional certificate-based authentication while enabling access to modern token-based services.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system performs preliminary actions by pre-configuring trusted certificate authorities and establishing the certificate validation rules before client access. This allows the intermediary to automatically recognize and validate client certificates without requiring real-time complex verification, thereby simplifying the client's access process while maintaining security.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If cloud services require OAuth tokens for authorization, then fine-grained access control is improved, but complexity of authentication flow increases

Engineering Contradiction:
Improvefine-grained access controlVSAvoidauthentication flow
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The intermediary consolidates the complex authentication flow by centralizing certificate validation, token generation, and token management operations. Instead of requiring the service to implement complex certificate validation logic or the client to manually obtain and manage OAuth tokens, the intermediary handles all these operations in one place, simplifying the overall system architecture while maintaining fine-grained access control capabilities through the generated tokens.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3618387B1Certificate-initiated access to services
Publication Date: 2021.04.14 SAP SE
  • EP3618387B1 patent drawingFigure 1~2
  • EP3618387B1 patent drawingFigure 3
  • EP3618387B1 patent drawingFigure 4

AI summary

A system includes terminating, at a reverse proxy, a mutual authentication handshake with a client computing system, the handshake including reception by the reverse proxy of a public key certificate associated with the client computing system, generating, by the reverse proxy, of an authentication token based on the public key certificate, receiving, at the reverse proxy, a request to access an application from the client computing system, forwarding the request and the authentication token from the reverse proxy to the application, receiving the request and the authentication token at the application, requesting, by the application, of an authorization token from an OAuth server based on the authentication token, receiving the authorization token from the OAuth server, storing the authorization token in association with a session identifier associated with the request received from the client computing system, and transmitting a response to the client computing system based on the authorization token and the request received from the client computing system.