Methods, systems, and devices for server control of client authorization proof of possession
Techniques for server control of client authorization proof of possession are described herein. In various embodiments, a first server provisions client authorization proof of possession for a client device a real-world time, a client public key, and a client private key. The first server generates provisioning response message(s) including the client public key, the client private key, the real-world time, and/or an assertion object, and sends the message(s) to the client device. In various embodiments, a client device obtains an authorization proof token generated based on a client public key, a client private key, and a real-world time provisioned by a first server. The client device generates a request and sends the request to a second server, the request includes the authorization proof token and an assertion object from the first server signed by a server private key and an expiration time and a reference to the client public key.
1 . A method comprising:
at a client device including one or more processors and a non-transitory memory:
obtaining from a first server a first client public key generated by the first server, a first client private key generated by the first server, a first assertion object generated by the first server, and a server notion of real-world time provisioned by the first server, wherein the first assertion object includes a reference to the first client public key and an expiration time, and the first assertion object is generated upon successful authentication of the client device by a second server, separate and distinct from the first server;
creating an authorization proof token by performing cryptographic operations using the first client public key, the first client private key, and a client notion of real-world time aligned with the server notion of real-world time;
generating a request including (a) the authorization proof token signed using the first client private key and (b) the first assertion object obtained from the first server; and
sending the request to the second server to prove the identity of the client device, including triggering the second server to one or more of validate the authorization proof token or verify the first assertion object.
2 . The method of claim 1 , further comprising:
receiving a code bound to an identity associated with the client device upon successful authentication by the second server;
sending an initial provisioning request to the first server via the second server, wherein the initial provisioning request triggers the second server to validate the code;
receiving from the first server via the second server an initial provisioning token upon validation of the code by the second server;
sending the initial provisioning token to the first server; and
receiving the first client public key, the first client private key, and the server notion of real-world time provisioned by the first server upon the first server validating the initial provisioning token.
3 . The method of claim 1 , further comprising:
determining whether the expiration time is within a threshold limit from the real-world time;
generating a provisioning refresh request and sending the provisioning refresh request to the first server in accordance with a determination that the expiration time is within the threshold limit from the client notion of real-world time, wherein the provisioning refresh request includes the first assertion object; and
obtaining from the first server a second client public key, a second client private key, and a second assertion object signed by the server private key.
4 . The method of claim 3 , further comprising:
encrypting and storing one or more of the first client public key, the first client private key, and the first assertion object in the non-transitory memory; and
updating the first client public key, the first client private key, and the first assertion object stored in the non-transitory memory based on the second client public key, the second client private key, and the second assertion object.
5 . The method of claim 1 , wherein the reference to the first client public key in the first assertion object includes the first client public key or a hash of the first client public key.
6 . The method of claim 1 , further comprising triggering the second server to:
validate the first assertion object, including matching the first client public key included in the first assertion object with the first client public key in the authorization proof token;
generate an application access token upon validating the first assertion object;
bind the application access token to the first client public key obtained from the authorization proof token; and
send the application access token to the client device.
7 . The method of claim 1 , further comprising:
generating an authorization request for access to a third server, wherein the authorization request includes an application access token and parameters associated with the third server; and
sending the authorization request to the second server, wherein the second server validates the authorization request including validating the application access token and validating a binding between the access token and the authorization proof token, generates a resource server access token for access to the third server based on the parameters, generates a binding between the resource server access token and the authorization proof token, and sends the resource server access token to the client device.
8 . The method of claim 7 , further comprising:
sending the resource server access token and the authorization proof token to the third server; and
obtaining resources from the third server upon the third server validating the resource server access token, the authorization proof token, and the binding between the resource server access token and the authorization proof token.
9 . The method of claim 8 , wherein the resources include a media manifest file, and sending the resource server access token and the authorization proof token to the third server includes:
intercepting a manifest request to the third server;
injecting a header of the authorization proof token and a hash of the resource server access token into the manifest request; and
sending the manifest request to the third server.
10 . The method of claim 9 , wherein the header includes:
a type of the authorization proof token;
a wrap for a symmetric signing key;
a key identifier obtained from the first server, wherein the key identifier is associated with a secret provisioned by the first server and shared between the first server and the third server, and the wrap for the symmetric signing key is generated by the first server by encrypting the symmetric signing key with the secret; and
a signature of the authorization proof token generated using the symmetric signing key.
11 . The method of claim 9 , wherein the header includes:
a type of the authorization proof token;
a key identifier obtained from the first server, wherein the key identifier is associated with a seed provisioned by the first server and shared between the first server and the third server, and the seed is used by the first server to derive a symmetric signing key; and
a signature of the authorization proof token generated using the symmetric signing key.
12 . The method of claim 9 , wherein the manifest request triggers the third server to validate the authorization proof token and the resource server access token based on the header of the authorization proof token and a representation of the first client public key and triggers the third server to send a manifest file to the client device upon successful validation of the authorization proof token and the resource server access token.
13 . The method of claim 12 , further comprising:
obtaining a session token from the third server, wherein the session token includes the header of the authorization proof token; and
sending the session token to the third server along with subsequent requests for media content referenced by the manifest file.
14 . The method of claim 8 , wherein the third server is distinct from the second server, and the method further includes:
requesting the third server to validate the resource server access token, the authorization proof token, and the binding when the client device requests the resources; and
requiring authentication by the second server upon the resource server access token, the authorization proof token, and the binding not being validated by the third server and a failed request to refresh the authorization proof token and the first assertion object by the first server.
15 . The method of claim 1 , further comprising:
sending a heartbeat request to the first server according to a periodic refresh interval;
receiving from the first server a message including configuration changes, wherein the configuration changes include the server notion of real-world time; and
applying the configuration changes in response to receiving the message, including aligning the client notion of real-world time with the server notion of real-world time.
16 . The method of claim 1 , further comprising:
requesting the authorization proof token and the first assertion object from the first server upon successful authentication of the client device by the second server; and
requiring re-authentication by the second server upon a failed request to obtain one or more of the authorization proof token and the first assertion object from the first server.
17 . A device comprising:
one or more processors; and
a non-transitory memory storing computer readable instructions, which when executed by the one or more processors, cause the device to:
obtain from a first server a first client public key generated by the first server, a first client private key generated by the first server, a first assertion object generated by the first server, and a server notion of real-world time provisioned by the first server, wherein the first assertion object includes a reference to the first client public key and an expiration time, and the first assertion object is generated upon successful authentication of the client device by a second server, separate and distinct from the first server;
create an authorization proof token by performing cryptographic operations using the first client public key, the first client private key, and a client notion of real-world time aligned with the server notion of real-world time;
generate a request including (a) the authorization proof token signed using the first client private key and (b) the first assertion object obtained from the first server; and
send the request to the second server to prove the identity of the client device, including triggering the second server to one or more of validate the authorization proof token or verify the first assertion object.
18 . The device of claim 17 , wherein the reference to the first client public key in the first assertion object includes the first client public key or a hash of the first client public key.
19 . A non-transitory computer-readable medium that includes computer-readable instructions stored thereon that are executed by one or more processors to perform operations comprising:
obtaining from a first server a first client public key generated by the first server, a first client private key generated by the first server, a first assertion object generated by the first server, and a server notion of real-world time provisioned by the first server, wherein the first assertion object includes a reference to the first client public key and an expiration time, and the first assertion object is generated upon successful authentication of the client device by a second server, separate and distinct from the first server;
creating an authorization proof token by performing cryptographic operations using the first client public key, the first client private key, and a client notion of real-world time aligned with the server notion of real-world time;
generating a request including (a) the authorization proof token signed using the first client private key and (b) the first assertion object obtained from the first server; and
sending the request to the second server to prove the identity of the client device, including triggering the second server to one or more of validate the authorization proof token or verify the first assertion object.
20 . The non-transitory computer-readable medium of claim 19 , wherein the reference to the first client public key in the first assertion object includes the first client public key or a hash of the first client public key.