# US 11,910,187 B2 · Invocation path security in distributed systems

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 11,910,187 B2
- Document ID: US11910187B2
- Status: Granted
- Kind: B2
- Application number: 16/984,085
- Filed: 2020-08-03
- Published: 2021-01-21
- Granted: 2024-02-20
- Earliest claimed: 2017-01-31
- Assignees: Pivotal Software, Inc.
- Applicants: Pivotal Software, Inc.
- Inventors: William Tran
- Web page: https://patentgrep.com/patent/US11910187B2

## CPC

- H04W 12/06: Authentication
- G06F 21/30: Authentication, i.e. establishing the identity or authorisation of security principals
- H04L 9/3247: {involving digital signatures}
- H04L 63/0428: {wherein the data content is protected, e.g. by encrypting or encapsulating the payload}
- H04L 63/06: {for supporting key management in a packet data network (cryptographic mechanisms or cryptographic arrangements for key management H04L9/08)}
- H04L 63/08: {for authentication of entities (cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32)}
- H04L 63/10: {for controlling access to devices or network resources}
- H04L 63/20: {for managing network security; network security policies in general (filtering policies H04L63/0227)}
- H04L 67/02: based on web technology, e.g. hypertext transfer protocol [HTTP]
- G06Q 10/087: Inventory or stock management, e.g. order filling, procurement or balancing against orders
- G06Q 30/0633: {Managing shopping lists, e.g. compiling or processing purchase lists (shipping orders G06Q10/083; order filling G06Q10/087)}
- H04W: WIRELESS COMMUNICATION NETWORKS (broadcast communication H04H; communication systems using wireless links for non-selective communication, e.g. wireless extensions H04M1/72)
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)
- G06Q: INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR

## Abstract

Systems, methods, and computer program products for an application to securely record and propagate an invocation context for invoking other applications are described. The applications being invoked not only receive a user's authentication token, but also authentication tokens of an entire invocation chain. Accordingly, the applications being invoked can verify a chain of custody through verification of nested, cryptographically signed payloads of a chain of authentication tokens. An application can thus verify identities of each application in the chain of custody, as well as the invocation contexts (e. g. the HTTP request method and path) in which each application in the chain invoked the next application.

## Claims

### Claim 1

A method comprising:
receiving, by an upstream application, a request from a user;
based on the upstream application authenticating a user, receiving an initial token that represents the authenticated user;
receiving, by a midstream application from the upstream application, a first invocation request, the first invocation request being associated with a first token generated by the upstream application, the first token including the initial token and the first token specifying a permissible audience of the first token, wherein the audience identifies recipients that the first token is intended for;
authenticating, by the midstream application, the first invocation request, including verifying the first token of the upstream application and the initial token within the first token;
verifying, by the midstream application, that the midstream application is an instance of the permissible audience of the first token;
upon successful verification, generating, by the midstream application, a second token comprising the initial token;
submitting, by the midstream application to a downstream application, a second invocation request in association with the second token and the first token;
receiving, by the downstream application from the midstream application, the second invocation request;
authenticating, by the downstream application, the second invocation request, including verifying the second token of the midstream application and the initial token within the second token; and
verifying, by the downstream application, that the midstream application is an instance of the permissible audience for the first token received from the upstream application.

### Claim 2 (depends on 1)

The method of claim 1, wherein each of the first token and the second token is a JSON Web token (JWT) and is transmitted in a header of a corresponding invocation request.

### Claim 3 (depends on 1)

The method of claim 1, wherein each of the first token and the second token is a single use token.

### Claim 4 (depends on 1)

The method of claim 1, wherein:
the initial token includes credentials of a user initiating the chain of invocations including the first invocation request and the second invocation request.

### Claim 5 (depends on 4)

The method of claim 4, further comprising authenticating the first invocation request by the midstream application, wherein:
authentication is performed on the first token, and
authorization is performed on the initial token.

### Claim 6 (depends on 4)

The method of claim 4, further comprising authenticating the second invocation request by the downstream application, wherein:
authentication is performed on the second token,
authentication is performed on the first token contained within the second token, and
authorization is performed on the initial token.

### Claim 7 (depends on 1)

The method of claim 1, further comprising authorizing the first invocation request by the midstream application, wherein authorization is based on a security policy that requires presence of one more authenticated tokens.

### Claim 8 (depends on 1)

The method of claim 1, wherein:
the first token includes a request field, the request field describing intended operation to be invoked by the upstream application on the midstream application, and
authenticating the first invocation request by the midstream application comprises determining whether the request field of the first token sufficiently describes the first invocation request.

### Claim 9 (depends on 1)

The method of claim 1, further comprising:
generating, by the upstream application, the first token, the first token specifying the permissible audience of the first token;
generating, by the upstream application, a first wrapper and associating the first token with the first wrapper; and
submitting, by the upstream application to the midstream application, the first invocation request in association with the first token and the first wrapper, wherein:
authenticating the first invocation request further comprises verifying, by the midstream application, a source of the first invocation request received from the upstream application using the first wrapper.

### Claim 10 (depends on 9)

The method of claim 9, further comprising:
discarding, by the midstream application, the first wrapper from the first token;
generating, by the midstream application, a second wrapper and associating the second token with the second wrapper; and
verifying, by the downstream application, a source of the second invocation request received from the midstream application using the second wrapper, wherein:
the downstream application does not have access to the discarded first wrapper.

### Claim 11

One or more non-transitory computer storage media encoded with computer program instructions that when executed by a plurality of computers cause the plurality of computers to perform operations comprising:
receiving, by an upstream application, a request from a user;
based on the upstream application authenticating a user, receiving an initial token that represents the authenticated user;
receiving, by a midstream application from the upstream application, a first invocation request, the first invocation request being associated with a first token generated by the upstream application, the first token including the initial token and the first token specifying a permissible audience of the first token, wherein the audience identifies recipients that the first token is intended for;
authenticating, by the midstream application, the first invocation request, including verifying the first token of the upstream application and the initial token within the first token;
verifying, by the midstream application, that the midstream application is an instance of the permissible audience of the first token;
upon successful verification, generating, by the midstream application, a second token comprising the initial token;
submitting, by the midstream application to a downstream application, a second invocation request in association with the second token and the first token;
receiving, by the downstream application from the midstream application, the second invocation request;
authenticating, by the downstream application, the second invocation request, including verifying the second token of the midstream application and the initial token within the second token; and
verifying, by the downstream application, that the midstream application is an instance of the permissible audience for the first token received from the upstream application.

### Claim 12 (depends on 11)

The one or more non-transitory computer storage media of claim 11, wherein each of the first token and the second token is a single use token.

### Claim 13 (depends on 11)

The one or more non-transitory computer storage media of claim 11, wherein:
the first token includes a request field, the request field describing intended operation to be invoked by the upstream application on the midstream application, and
authenticating the first invocation request by the midstream application comprises determining whether the request field of the first token sufficiently describes the first invocation request.

### Claim 14 (depends on 11)

The one or more non-transitory computer storage media of claim 11, the operations further comprising:
generating, by the upstream application, the first token, the first token specifying the permissible audience of the first token;
generating, by the upstream application, a first wrapper and associating the first token with the first wrapper; and
submitting, by the upstream application to the midstream application, the first invocation request in association with the first token and the first wrapper, wherein:
authenticating the first invocation request further comprises verifying, by the midstream application, a source of the first invocation request received from the upstream application using the first wrapper.

### Claim 15 (depends on 14)

The one or more non-transitory computer storage media of claim 14, the operations further comprising:
discarding, by the midstream application, the first wrapper from the first token;
generating, by the midstream application, a second wrapper and associating the second token with the second wrapper; and
verifying, by the downstream application, a source of the second invocation request received from the midstream application using the second wrapper, wherein:
the downstream application does not have access to the discarded first wrapper.

### Claim 16

A system comprising one or more computers and one or more storage devices on which are stored instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising:
receiving, by an upstream application, a request from a user;
based on the upstream application authenticating a user, receiving an initial token that represents the authenticated user;
receiving, by a midstream application from upstream application, a first invocation request, the first invocation request being associated with a first token generated by the upstream application, the first token including the initial token and the first token specifying a permissible audience of the first token, wherein the audience identifies recipients that the first token is intended for;
authenticating, by the midstream application, the first invocation request, including verifying the first token of the upstream application and the initial token within the first token;
verifying, by the midstream application, that the midstream application is an instance of the permissible audience of the first token;
upon successful verification, generating, by the midstream application, a second token comprising the initial token;
submitting, by the midstream application to a downstream application, a second invocation request in association with the second token and the first token;
receiving, by the downstream application from the midstream application, the second invocation request;
authenticating, by the downstream application, the second invocation request, including verifying the second token of the midstream application and the initial token within the second token; and
verifying, by the downstream application, that the midstream application is an instance of the permissible audience for the first token received from the upstream application.

### Claim 17 (depends on 16)

The system of claim 16, wherein each of the first token and the second token is a single use token.

### Claim 18 (depends on 16)

The system of claim 16, wherein:
the first token includes a request field, the request field describing intended operation to be invoked by the upstream application on the midstream application, and
authenticating the first invocation request by the midstream application comprises determining whether the request field of the first token sufficiently describes the first invocation request.

### Claim 19 (depends on 16)

The system of claim 16, the operations further comprising:
generating, by the upstream application, the first token, the first token specifying the permissible audience of the first token;
generating, by the upstream application, a first wrapper and associating the first token with the first wrapper; and
submitting, by the upstream application to the midstream application, the first invocation request in association with the first token and the first wrapper, wherein:
authenticating the first invocation request further comprises verifying, by the midstream application, a source of the first invocation request received from the upstream application using the first wrapper.

### Claim 20 (depends on 19)

The system of claim 19, the operations further comprising:
discarding, by the midstream application, the first wrapper from the first token;
generating, by the midstream application, a second wrapper and associating the second token with the second wrapper; and
verifying, by the downstream application, a source of the second invocation request received from the midstream application using the second wrapper, wherein:
the downstream application does not have access to the discarded first wrapper.