IP Library › Granted Patent US 12,381,732
Granted Patent B2
US 12,381,732 · App. 18/209,011 · Granted Aug 5, 2025

Single-use authorization codes in self-contained format

Inventor: Radoslav Ivanov Sugarev (Petrich, BG)
Assignee: SAP SE
H04L9/3228H04L9/085H04L9/3073H04L9/3213
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,381,732
App. No.
18/209,011
Granted
Aug 5, 2025
Kind
B2
Abstract

The present disclosure relates to computer-implemented methods, software, and systems for generating access tokens at an authentication server based on authorization codes. A first authorization server from a set of authorization servers receives a request for authorization of a request to access a resource by a resource owner. The first authorization server validates the request for authorization of the request to generate an authorization code. In response to successful validation of the request for authorization to generate the authorization code, the first authorization server generates a single-use authorization code by signing the generated authorization code with a unique private key. A unique public key is maintained for verifying the signed authorization code. The single-use authorization code is generated in a self-contained format. The single-use authorization code is provided to the client application for generation of an access token by one of the authorization servers from the set of authorization servers.

Claims (41)

1. A computer implemented method for generating authorization codes at a set of authorization servers, wherein the set of authorization servers are organized to process requests for accessing resources and generate access tokens according to a non-consensual organization, where each authorization server is assigned the same right and role, the method comprising:

receiving, from a client application and at a second authorization server, a request including an authorization code for requesting access to a resource by a client application, wherein the authorization code is signed with a signature that is generated based on a private key generated at a first authorization server of the set of authorization servers, wherein each authorization server of the set of authorization servers is configured to generate and maintain a respective pair of a public key and a private key;

in response to receiving the request, generating, at the second authorization server, an access token based on verifying the signature of the authorization code, wherein verifying the access token comprises:

querying other authorization servers of the set of authorization servers to determine that the first authorization server had signed the authorization code; and

fetching a generated public key maintained at the first authorization server to verify the signature of the authorization code; and

providing the access token to the client application to access the resource.

2. The method of claim 1 , wherein the first authorization server generates the private key and the corresponding public key that are maintained in-memory at the first authorization server.

3. The method of claim 1 , comprising:

in response to fetching the public key, sending an instruction from the second authorization server to the first authorization server to delete the public key and the private key as maintained at the first authorization server.

4. The method of claim 1 , comprising:

in response to providing the public key to the second authorization server, automatically determining by the first authorization server to delete the public key and the private key.

5. The method of claim 1 , wherein providing the access token comprises:

in response to receiving the access token generation request and obtaining the public key at the second authorization server, generating the access token to be provided to the client application.

6. The method of claim 1 , wherein the authorization code is generated as a single-use authorization code by signing the generated authorization code with a unique private key as the private key, and wherein the public key used for verifying the authorization code is an unique public key maintained for verifying the signed authorization code at the first authorization server.

7. The method of claim 1 , wherein the authorization code is used as a single-use authorization code generated in a self-contained format.

8. The method of claim 1 , comprising:

generating, at the first authorization server, a unique key pair including the public key as a unique public key and the private key as a unique private key, wherein the unique key pair is generated in association with the authorization code.

9. A non-transitory, computer-readable medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations, the operations comprising:

receiving, from a client application and at a second authorization server, a request including an authorization code for requesting access to a resource by a client application, wherein the authorization code is signed with a signature that is generated based on a private key generated at a first authorization server of a set of authorization servers, wherein each authorization server of the set of authorization servers is configured to generate and maintain a respective pair of a public key and a private key, wherein the set of authorization servers are organized to process requests for accessing resources and generate access tokens according to a non-consensual organization, where each authorization server is assigned the same right and role;

in response to receiving the request, generating, at the second authorization server, an access token based on verifying the signature of the authorization code, wherein verifying the access token comprises:

querying other authorization servers of the set of authorization servers to determine that the first authorization server had signed the authorization code; and

fetching a generated public key maintained at the first authorization server to verify the signature of the authorization code; and

providing the access token to the client application to access the resource.

10. The computer-readable medium of claim 9 , wherein the first authorization server generates the private key and the corresponding public key that are maintained in-memory at the first authorization server.

11. The computer-readable medium of claim 9 , wherein the operations further comprise:

in response to fetching the public key, sending an instruction from the second authorization server to the first authorization server to delete the public key and the private key as maintained at the first authorization server.

12. The computer-readable medium of claim 9 , wherein providing the access token further comprise:

in response to providing the public key to the second authorization server, automatically determining by the first authorization server to delete the public key and the private key.

13. A system comprising:

a computing device; and

a computer-readable storage device coupled to the computing device and having instructions stored thereon which, when executed by the computing device, cause the computing device to perform operations, the operations comprising:

receiving, from a client application and at a second authorization server, a request including an authorization code for requesting access to a resource by a client application, wherein the authorization code is signed with a signature that is generated based on a private key generated at a first authorization server of a set of authorization servers, wherein each authorization server of the set of authorization servers is configured to generate and maintain a respective pair of a public key and a private key, wherein the set of authorization servers are organized to process requests for accessing resources and generate access tokens according to a non-consensual organization, where each authorization server is assigned the same right and role;

in response to receiving the request, generating, at the second authorization server, an access token based on verifying the signature of the authorization code, wherein verifying the access token comprises:

querying other authorization servers of the set of authorization servers to determine that the first authorization server had signed the authorization code; and

fetching a generated public key maintained at the first authorization server to verify the signature of the authorization code; and

providing the access token to the client application to access the resource.

14. The system of claim 13 , wherein the first authorization server generates the private key and the corresponding public key that are maintained in-memory at the first authorization server.

15. The system of claim 13 , wherein the system further comprises instructions which when executed cause the computing device to perform operations comprising:

in response to fetching the public key, sending an instruction from the second authorization server to the first authorization server to delete the public key and the private key as maintained at the first authorization server.

16. The system of claim 13 , wherein providing the access token comprises:

in response to providing the public key to the second authorization server, automatically determining by the first authorization server to delete the public key and the private key.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jun 13, 2023
From: SUGAREV, RADOSLAV IVANOV
To: SAP SE
Reel/Frame 063931/0271 →
Continuity (2)
Continuation 17158509 · Jan 26, 2021
Related Publication 20230353367A1 · Nov 2, 2023
References Cited (67)
US 6959393B2 · Hollis et al. · 2005 [cited by applicant]
US 7778931B2 · Rits · 2010 [cited by applicant]
US 8019860B2 · Ivanov et al. · 2011 [cited by applicant]
US 8650622B2 · Murakami et al. · 2014 [cited by applicant]
US 8700899B1 · Juels · 2014 [cited by applicant]
US 9197408B2 · Amato · 2015 [cited by applicant]
US 9256413B2 · Ivanov et al. · 2016 [cited by applicant]
US 9344410B1 · Lin · 2016 [cited by applicant]
US 9819672B1 · Machani · 2017 [cited by applicant]
US 9900212B2 · Pavlov et al. · 2018 [cited by applicant]
US 10469484B1 · Chen et al. · 2019 [cited by applicant]
US 10887301B1 · Vera et al. · 2021 [cited by applicant]
US 11140146B2 · Suraparaju · 2021 [cited by examiner]
US 11349662B2 · Chang et al. · 2022 [cited by applicant]
US 11503012B1 · Yancey · 2022 [cited by examiner]
US 11503013B2 · Bruckner · 2022 [cited by examiner]
US 11546159B2 · Sugarev · 2023 [cited by applicant]
US 11563580B2 · Sugarev · 2023 [cited by applicant]
US 20090258631A1 · Forsberg et al. · 2009 [cited by applicant]
US 20130007846A1 · Murakami et al. · 2013 [cited by applicant]
US 20150163061A1 · Gupta · 2015 [cited by applicant]
US 20150348015A1 · Ren et al. · 2015 [cited by applicant]
US 20160179494A1 · Pavlov et al. · 2016 [cited by applicant]
US 20170085563A1 · Royyuru · 2017 [cited by applicant]
US 20180034796A1 · Ross et al. · 2018 [cited by applicant]
US 20180075231A1 · Subramanian · 2018 [cited by examiner]
US 20180077144A1 · Gangawane · 2018 [cited by examiner]
US 20180167367A1 · John et al. · 2018 [cited by applicant]
US 20190251241A1 · Bykampadi et al. · 2019 [cited by applicant]
US 20190306138A1 · Carru et al. · 2019 [cited by applicant]
US 20190372958A1 · Dunjic et al. · 2019 [cited by applicant]
US 20190394042A1 · Peddada · 2019 [cited by applicant]
US 20200014681A1 · Sajja et al. · 2020 [cited by applicant]
US 20200059466A1 · Jiang et al. · 2020 [cited by applicant]
US 20200067711A1 · Abadir et al. · 2020 [cited by applicant]
US 20200211002A1 · Steinberg et al. · 2020 [cited by applicant]
US 20200213297A1 · Suraparaju · 2020 [cited by examiner]
US 20210037005A1 · Ghosh · 2021 [cited by examiner]
US 20210258299A1 · Bruckner · 2021 [cited by examiner]
US 20210288808A1 · Bahety · 2021 [cited by applicant]
US 20210336791A1 · Choi et al. · 2021 [cited by applicant]
US 20220094547A1 · Duchastel et al. · 2022 [cited by applicant]
US 20220138306A1 · Theodor et al. · 2022 [cited by applicant]
US 20220232003A1 · Smolny et al. · 2022 [cited by applicant]
US 20220239491A1 · Sugarev · 2022 [cited by examiner]
US 20220377064A1 · Raj · 2022 [cited by applicant]
US 20220383417A1 · Cummings · 2022 [cited by applicant]
US 20230138368A1 · Sugarev · 2023 [cited by applicant]
US 20230146453A1 · Wang et al. · 2023 [cited by applicant]
US 20230353367A1 · Sugarev · 2023 [cited by examiner]
US 20240007473A1 · Gjermshus · 2024 [cited by examiner]
CN 104255007 · 2014 [cited by applicant]
CN 108322472 · 2018 [cited by applicant]
CN 108463982 · 2018 [cited by applicant]
CN 111131301 · 2020 [cited by applicant]
EP 3422630 · 2019 [cited by applicant]
Office Action in Chinese Appln. No. 202111281843.X, dated Jun. 3, 2023, 18 pages (with English translation). [cited by applicant]
Faynberg et al., “On dynamic access control in Web 2.0 and beyond: Trends and technologies.” Bell Labs Technical Journal 16.2, Sep. 2011, 199-218, 20 pages. [cited by applicant]
Hardt, “The OAuth 2.0 Authorization Framework”, Oct. 2012, [retrieved on Jan. 27, 2021], retrieved from: URL <https://www.rfc-editor.org/info/rfc6749>, 76 pages. [cited by applicant]
Jones et al., “JSON Web Signature (JWS)”, May 2015, [retrieved on Jan. 27, 2021], retrieved from: URL <https://www.rfc-editor.org/info/rfc7515>, 59 pages. [cited by applicant]
Jones et al., “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants”, May 2015, [retrieved on Jan. 27, 2021], retrieved from: URL <https://www.rfc-editor.org/info/rfc7523>, 12 pages. [cited by applicant]
Jones et al., “JSON Web Token (JWT)”, May 2015, [retrieved on Jan. 27, 2021], retrieved from: URL <https://www.rfc-editor.org/info/rfc7519>, 30 pages. [cited by applicant]
Jwt.io [online], “Introduction to JSON Web Tokens” Oct. 2015, [retrieved on Jan. 27, 2021], retrieved from: URL <https://jwt.io/introduction/>, 11 pages. [cited by applicant]
Raft.github.io [online], “The Raft Consensus Algorithm” Sep. 2015, [retrieved on Jan. 27, 2021], retrieved from: URL <https://raft.github.io/>, 11 pages. [cited by applicant]
Extended European Search Report issued in European Application No. 21205149.4 on Apr. 7, 2022, 7 pages. [cited by applicant]
U.S. Appl. No. 17/096,605, filed Nov. 12, 2020, Sugarev. [cited by applicant]
Non-Final Office Action in U.S. Appl. No. 18/148,935, mailed on Feb. 9, 2024, 21 pages. [cited by applicant]