Authentication token with client key

• US 10,505,916 B2
• Filed: 10/19/2017
• Issued: 12/10/2019
• Est. Priority Date: 10/19/2017
• Status: Active Grant

• Current Assignee: T-Mobile USA, Inc. (Deutsche Telekom AG)
• Original Assignee: T-Mobile USA, Inc. (Deutsche Telekom AG)
• Inventors: Engan, Michael, McDorman, Douglas, Velusamy, Senthil Kumar Mulluppadi, Subramaniam, Komethagan
• Primary Examiner(s): Lwin, Maung T
• Application Number:
  US15/788,731
• Publication Number:
  US 20190124070A1
• Time in Patent Office: 782 Days
• Field of Search: None
• CPC Class Codes: H04L 63/0272 Virtual private networks
• CPC Class Codes: H04L 63/0435 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption cryptographic mechanisms or cryptographic arrangements for symmetric key encryption H04L9/06
• CPC Class Codes: H04L 63/0442 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption cryptographic mechanisms or cryptographic arrangements for public-key encryption H04L9/30
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/0815 providing single-sign-on or federations
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources
• CPC Class Codes: H04L 63/166 at the transport layer
• CPC Class Codes: H04L 9/3213 using tickets or tokens, e.g. Kerberos network architectures or network communication protocols for entities authentication using tickets in a packet data network H04L63/0807
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853
• CPC Class Codes: H04L 9/3247 involving digital signatures
• CPC Class Codes: H04W 12/03 Protecting confidentiality, e.g. by encryption
• CPC Class Codes: H04W 12/069 using certificates or pre-shared keys

Abstract

Techniques are described for using two tokens to request access to a secure server. The tokens allow the server to verify, without an external call, that the requesting device is one identified in the request and that the requesting device is authorized by a trusted identity provider. A first token is an authentication token issued by the trusted identity provider and including a client device public key. The second token is a proof-of-possession token that is signed by a client device using a client device private key corresponding to the client device public key. The server obtains the client device public key from the authentication token, and then uses the client device public key to validate the proof-of-possession token. The authentication token can be re-used by a server creating its own proof-of-possession token for presentation to a second server to access a secure service on the second server.

Claims

1. A method, comprising:

receiving a first request to access a secure service, the first request including a first token and a second token;

extracting a client public key from the first token;

validating the second token with the client public key extracted from the first token;

authorizing access to the secure service upon validation of the second token;

creating a third token signed by a server private key; and

transmitting to a second server a second request for access to the second server, the second request including the first token and the third token,

wherein the first token is configured to validate a client device for the access to the second server, and the third token is configured to validate a requesting entity of the second request for access to the second server.

2. The method as recited in claim 1, wherein the second token authenticates a source of the first request.

3. The method as recited in claim 1, wherein the first token is an authentication token created and signed by a trusted identity provider, and wherein the extracting further comprises validating the first token with an identity provider public key to obtain the client public key.

4. The method as recited in claim 1, wherein the first request is a HyperText Transfer Protocol (HTTP) request containing the first token and the second token in an authorization header.

5. The method as recited in claim 1, wherein the authorizing access to the secure service is based on one or both of the first and second tokens without a call to an external service to validate the first request.

6. The method as recited in claim 1, wherein the second server authorizes access by the client device based on validation of at least the first token.

7. One or more non-transitory computer-readable media, containing computer executable instructions, comprising:

a first code segment that, when executed, receives a first request from a client device to access a secure service, the first request including a first token and a second token;

a second code segment that, when executed, extracts a client device public key from the first token;

a third code segment that, when executed, validates the second token using the client device public key extracted from the first token;

a fourth code segment that, when executed, authorizes access to the secure service upon successful validation of the second token;

a fifth code segment that, when executed, creates a third token signed with a first server private key; and

a sixth code segment that, when executed, creates a second request to a second server, the second request including the first token and the third token,

wherein the third token is configured to be validatable with a first server public key, and the first token is configured to be validatable with an identity provider public key.

8. The one or more non-transitory computer-readable media as recited in claim 7, wherein the client device public key is configured to be extractable from the first token using a public key of an identity provider that created the first token.

9. The one or more non-transitory computer-readable media as recited in claim 7, wherein the first token and the second token are received included in an authorization header of an HTTP request.

10. The one or more non-transitory computer-readable media as recited in claim 7, wherein the first token is a JSON Web Token that stores the client device public key in a digitally signed body of the token.