Server-Side OAuth Token Management for Browser Apps

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In-browser applications face security issues due to the lack of a secure place to store access tokens, as JavaScript-based applications running inside browsers cannot securely store access tokens, leading to potential exposure and misuse.

Innovation Solution

A server-side service is implemented to manage secure storage of access tokens using the OAuth 2.0 authorization code flow, allowing in-browser applications to securely obtain and use access tokens without exposing them to the user agent, by providing endpoints for user-specific configurations, session management, and secure token storage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If in-browser applications store access tokens locally, then applications can access protected resources, but security is compromised due to lack of secure storage

Engineering Contradiction:
Improveaccess to protected resourcesVSAvoidsecurity
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent introduces a server-side service as an intermediary between the in-browser application and the OAuth authorization server. This service manages access tokens securely on the server, receiving them from the OAuth flow and making them available to the browser application through controlled interfaces, thus eliminating the need for local token storage while maintaining access functionality

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The solution moves the token storage dimension from the client-side (browser) to the server-side, creating a new architectural layer. Instead of storing tokens in the browser's local storage or memory, tokens are stored and managed in a secure server environment, accessed by the browser application through authenticated requests

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Reliability

If OAuth 2.0 authorization code flow is used, then security is improved by not exposing passwords, but in-browser applications cannot securely store the resulting access tokens

Engineering Contradiction:
ImprovesecurityVSAvoidtoken storage capability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The server-side service acts as a mediator that bridges the OAuth 2.0 authorization code flow and the in-browser application. It receives access tokens from the OAuth flow, secures them in server storage, and provides controlled access to the browser application, thus enabling OAuth usage without requiring browser-side token storage capability

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent extracts the token storage function from the browser application environment and places it in a dedicated server-side service. This separation allows the browser application to focus on its core functionality while the server service handles the complex security requirements of token management

Inventive Principle:
Principle #2Taking out (Extraction)

3Ease of operation

If access tokens are exposed to the user agent, then in-browser applications can use them, but security is compromised due to potential exposure and misuse

Engineering Contradiction:
Improveapplication functionalityVSAvoidtoken exposure and misuse
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The server-side service serves as an intermediary that controls all interactions between the browser application and access tokens. The application never directly receives or handles tokens; instead, it makes authenticated requests to the server service, which retrieves and uses tokens as needed, thus eliminating token exposure to the user agent

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent extracts access tokens from the browser environment entirely, preventing any direct exposure to the user agent. Tokens remain exclusively in the server-side service, which manages their lifecycle and usage without requiring them to be present in or accessible to the browser application

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentEP3333744B1Authorization code flow for in-browser applications
Publication Date: 2020.09.30 SAP SE
  • EP3333744B1 patent drawingFigure 1
  • EP3333744B1 patent drawingFigure 2
  • EP3333744B1 patent drawingFigure 3A

AI summary

A system receives a request from an in-browser application for an authorization code, creates a session that re-directs the in-browser application to an authorization server, and receives the authorization code from the authorization server by way of the in-browser application. The system requests an access token from the authorization server and receives the access token from the authorization server. The system then receives a request from the in-browser application for a resource, uses the access token to request the resource from a third-party resource server, and returns the resource to the in-browser application.