OAuth Authorization Server Attested Client Authentication

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing OAuth and OpenID Connect protocols do not effectively authenticate clients running on mobile and web applications, leading to suboptimal user experience and security risks, as they do not adhere to REST principles and cannot support multiple-factor authentication without custom solutions.

Innovation Solution

An OAuth authorization server method that uses client attestation tokens, proof of possession of private keys, and a hypermedia-based authentication state machine to authenticate users, ensuring that only attested clients can proceed through the authentication process, thereby reducing the risk of security breaches and enabling REST-compliant APIs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If OAuth and OpenID Connect protocols are used for client authentication, then interoperability and REST-like authentication are achieved, but clients cannot be attested to be authentic (public/unauthenticated clients)

Engineering Contradiction:

ImproveinteroperabilityVSAvoidclient authentication

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary attestation of the client application code before authentication. The attestation process verifies the integrity and authenticity of the client application, issuing an attestation token that proves the client is genuine. This preliminary action ensures that only authenticated clients can proceed with the OAuth flow, resolving the contradiction between interoperability and client authentication.

Inventive Principle:

Principle #10Preliminary action

2Ease of operation

If Single Page Applications (SPA) and mobile applications are deployed, then accessibility and ease of use are improved, but credentials can be obtained through decompilation or source code viewing (security risk)

Engineering Contradiction:

ImproveaccessibilityVSAvoidcredential exposure

Core Design Contradiction:

Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The invention extracts the authentication capability from the client application code itself. Instead of embedding credentials in the application, the system uses the application code's integrity as the authentication mechanism. The attestation process verifies the code without exposing any secrets, and the authenticated client uses this attestation token for subsequent OAuth operations, eliminating credential exposure risks while maintaining SPA and mobile app accessibility.

Inventive Principle:

Principle #2Taking out (Extraction)

3Productivity

If Resource Owner Password Credentials Grant is used for API-driven login, then authentication can be performed, but it cannot support multiple factors of authentication and does not adhere to REST principles

Engineering Contradiction:

Improveauthentication capabilityVSAvoidauthentication methods

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

The system creates a universal authentication framework that works across multiple authentication methods. The attestation-based client authentication is method-agnostic and can be combined with any user authentication mechanism (password, MFA, biometrics, etc.). The OAuth 2.0 flow provides a unified RESTful interface that supports various grant types and authentication factors, resolving the limitation of password-only authentication while maintaining productivity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

4Adaptability or versatility

If browser-based authentication is required, then OAuth and OpenID Connect can be implemented, but it creates barriers for users and delegates authentication suboptimally

Engineering Contradiction:

Improveprotocol compatibilityVSAvoiduser experience

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The invention introduces an attestation service as an intermediary between the client application and the authorization server. This intermediary verifies the client's authenticity through code attestation and issues an attestation token. The client then uses this token directly in OAuth requests without needing to redirect to a browser, eliminating the browser dependency while maintaining protocol compatibility and improving user experience.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS12149612B2Login and consent methodology that follows rest principles and uses the OAUTH protocol with attested clients

Publication Date: 2024.11.19 CURITY AB

AI summary

Authentication of a user of an OAuth client by an OAuth authorization server, comprising exposing an authentication state machine, where the states of the state machine are hypermedia-based representations of login resources, and transitions between states are represented by hypermedia links, wherein the authentication state machine is exposed to the client by an API adhering to the principles of REpresentational State Transfer (REST). When the final state of the state machine has been reached, a secondary access token is issued to the client, thereby authenticating the user, wherein hypermedia representations which are sent to the client are encoded so as to be readily parsable by the client.