Anand Bahety

Technologies are shown for secure token refresh where a client receives a first access token from an authentication service, generates an asymmetric key pair, stores the first access token in association with a private key, and sends a public key to the authentication service. The service stores the public key in association with the first access token. The client sends a refresh token request to the service with the first access token. The service responds with a verification request with proof data. The client signs the proof data with the private key and sends the signed proof data to the service. The service verifies the signed proof data using the public key associated with the first access token, creates a second access token that is stored in association with the public key, and sends the second access token to the client, which stores it in association with the private key.

Technologies are shown for secure token refresh where a client receives a first access token from an authentication service, generates an asymmetric key pair, stores the first access token in association with a private key, and sends a public key to the authentication service. The service stores the public key in association with the first access token. The client sends a refresh token request to the service with the first access token. The service responds with a verification request with proof data. The client signs the proof data with the private key and sends the signed proof data to the service. The service verifies the signed proof data using the public key associated with the first access token, creates a second access token that is stored in association with the public key, and sends the second access token to the client, which stores it in association with the private key.

A system, method, and computer program product are provided for securing authorization tokens using client instance specific secrets. Tokens are valid for service requests only if time constraints and additional security constraints are met by additional information stored in the token in hashed form. A required comparison of a timestamp in a client service request header to the current server time limits the useful token life, e.g., to a few minutes. The service request header also includes data generated based on a secret previously assigned to a specific client instance. The secret may be generated by the server according to a public/private key scheme and sent to a particular client instance only once, e.g., during initial device registration. The secret may be omitted from service requests for public information. Service request headers may include device identifiers, so that service requests from known rogue clients may be ignored.

Systems and methods for implementing an identity assertion framework to authenticate a user in a federation of security domains are provided. A first security token service (STS) is configured to receive a request for a first token from a consumer and to issue the first token to the consumer. The first STS is associated with a first security domain, and the first token is issued according to a first issuing policy of the first security domain. A service provider within a second security domain receives the first token and makes a determination whether the first token is invalid in the second security domain. A second STS receives the first token from the service provider, determines that the first token was issued by the first STS, and validates the first token according to a federation policy between the first security domain and the second security domain.

Systems and methods for implementing an identity assertion framework to authenticate a user in a federation of security domains are provided. A first security token service (STS) is configured to receive a request for a first token from a consumer and to issue the first token to the consumer. The first STS is associated with a first security domain, and the first token is issued according to a first issuing policy of the first security domain. A service provider within a second security domain receives the first token and makes a determination whether the first token is invalid in the second security domain. A second STS receives the first token from the service provider, determines that the first token was issued by the first sts, and validates the first token according to a federation policy between the first security domain and the second security domain