Abstract: According to examples, an apparatus may include a processor that may receive a request from a first device for an authentication token for access to a service, determine whether the first device is authorized to receive the authentication token for access to the service, and based on a determination that the first device is authorized to receive the authentication token for access to the service, generate a machine-readable code including the authentication token that a second device is to use for access to the service by the second device. The processor may also send the generated machine-readable code to the first device. The first device may display the machine-readable code and the second device may use a captured image of the machine-readable code to establish an authenticated session to the service on the second device.

Abstract: According to examples, an apparatus may include a processor that may receive a request from a first device for an authentication token for access to a service, determine whether the first device is authorized to receive the authentication token for access to the service, and based on a determination that the first device is authorized to receive the authentication token for access to the service, generate a machine-readable code including the authentication token that a second device is to use for access to the service by the second device. The processor may also send the generated machine-readable code to the first device. The first device may display the machine-readable code and the second device may use a captured image of the machine-readable code to establish an authenticated session to the service on the second device.

Abstract: Authenticating a secure session between a first user entity and an identity provider using a second user entity. The method includes receiving a request for a session from an entity that purports to be the first user entity. The method further includes sending authentication context from the request, and wherein the authentication context for the request arrives at the second user entity. The method further includes receiving an indication that the authentication context has been verified. As a result, the method further includes authenticating a secure session between a first user entity and an identity provider or approving a secure transaction.

Abstract: Authenticating a secure session between a first user entity and an identity provider using a second user entity. The method includes receiving a request for a session from an entity that purports to be the first user entity. The method further includes sending authentication context from the request, and wherein the authentication context for the request arrives at the second user entity. The method further includes receiving an indication that the authentication context has been verified. As a result, the method further includes authenticating a secure session between a first user entity and an identity provider or approving a secure transaction.

Abstract: Binding a security token to a client token binder, such as a trusted platform module, is provided. A bound security token can only be used on the client on which it was obtained. A secret binding key (kbind) is established between the client and an STS. The client derives a key (kmac) from kbind, signs a security token request with kmac, and instructs the STS to bind the requested security token to kbind. The STS validates the request by deriving kmac using a client-provided nonce and kbind to MAC the message and compare the MAC values. If the request is validated, the STS generates a response comprising the requested security token, derives two keys from kbind: one to sign the response and one to encrypt the response, and sends the response to the client. Only a device comprising kbind is enabled to use the bound security token, providing increased security.

Abstract: Authenticating a secure session between a first user entity and an identity provider using a second user entity. The method includes receiving a request for a session from an entity that purports to be the first user entity. The method further includes sending authentication context from the request, and wherein the authentication context for the request arrives at the second user entity. The method further includes receiving an indication that the authentication context has been verified. As a result, the method further includes authenticating a secure session between a first user entity and an identity provider or approving a secure transaction.

Abstract: Authenticating a secure session between a first user entity and an identity provider using a second user entity. The method receiving a request for a session from an entity that purports to be the first user entity. The method further includes sending authentication context from the request, and wherein the authentication context for the request arrives at the second user entity. The method further includes receiving an indication that the authentication context has been verified. As a result, the method further includes authenticating a secure session between a first user entity and an identity provider or approving a secure transaction.

Abstract: User-authentication-based approval of a first device via communication with a second device over a channel (e.g., an insecure channel) is described. The first device receives a session ID and first user-observable information, or an identifier thereof, from an identity provider, presents the first user-observable information to a user, and sends the session ID to the second device. The second device sends the session ID to the identity provider to obtain therefrom second user-observable information, or an identifier thereof, and a security challenge. The second user-observable information bears a user-discernable relationship to the first user-observable information and is presented to the user by the second device. The second device is capable of generating a response to the security challenge for transmission to the identity provider based at least on input received from the user, the response to the security challenge being indicative of the suitability of the first device for approval.

Abstract: Binding a security token to a client token binder, such as a trusted platform module, is provided. A bound security token can only be used on the client on which it was obtained. A secret binding key (kbind) is established between the client and an STS. The client derives a key (kmac) from kbind, signs a security token request with kmac, and instructs the STS to bind the requested security token to kbind. The STS validates the request by deriving kmac using a client-provided nonce and kbind to MAC the message and compare the MAC values. If the request is validated, the STS generates a response comprising the requested security token, derives two keys from kbind: one to sign the response and one to encrypt the response, and sends the response to the client. Only a device comprising kbind is enabled to use the bound security token, providing increased security.

Abstract: Embodiments are directed to validating the identity of a user. In one scenario, a computer system determines that a login account has been created for a user, where the creation includes generation of a first identifier for the user based on a user's determined location at the time of account creation. The computer system next receives a login attempt from the user that includes a second, different identifier and one or more login credentials. The computer system then determines the location from which the login attempt was received and, using the second identifier and the determined login location, identifies the user account corresponding to the user. The computer system further authenticates the user upon determining that the second identifier and login location match the first identifier.

Abstract: Embodiments are directed to validating the identity of a user. In one scenario, a computer system determines that a login account has been created for a user, where the creation includes generation of a first identifier for the user based on a user's determined location at the time of account creation. The computer system next receives a login attempt from the user that includes a second, different identifier and one or more login credentials. The computer system then determines the location from which the login attempt was received and, using the second identifier and the determined login location, identifies the user account corresponding to the user. The computer system further authenticates the user upon determining that the second identifier and login location match the first identifier.

Abstract: User-authentication-based approval of a first device via communication with a second device over a channel (e.g., an insecure channel) is described. The first device receives a session ID and first user-observable information, or an identifier thereof, from an identity provider, presents the first user-observable information to a user, and sends the session ID to the second device. The second device sends the session ID to the identity provider to obtain therefrom second user-observable information, or an identifier thereof, and a security challenge. The second user-observable information bears a user-discernable relationship to the first user-observable information and is presented to the user by the second device. The second device is capable of generating a response to the security challenge for transmission to the identity provider based at least on input received from the user, the response to the security challenge being indicative of the suitability of the first device for approval.

Abstract: Methods, systems, apparatuses, and computer program products are provided for authentication of users in a service-to-service context. At a first service, a user authentication token is received from a client device that was obtained from an identity provider. The user authentication token was received to enable access to the first service by a user. The user is authenticated based on the user authentication token. A second service is determined to be needed to be accessed by the first service on behalf of the user. The user authentication token is converted into a proxy token that is not convertible back to the user authentication token. The proxy token is forwarded from the first service to the second service to enable access to the second service. A response is received by the first service from the second service due to the user having been authenticated based on the proxy token.

Abstract: Sharing resources on a network include, for example, a domain controller hierarchy scheme, which is used in some implementations to organize and share both secure and non-secure resources in an efficient manner. Using authentication information can be used to architect a trustworthy system to divulging sensitive client data (such as user/computer passwords) to a host system. The sensitive client data can be released to the host system when a client establishes a relationship having a degree of trust with the host.

Abstract: An exemplary group ticket for a Kerberos protocol includes a service ticket encrypted with a dynamic group key and a plurality of enveloped pairs where each pair includes a name associated with a member of a group and an encrypted the dynamic group key for decryption by a key possessed by the member of the group where decryption of an encrypted dynamic group key allows for decryption of the service ticket. Other exemplary methods, systems, etc., are also disclosed.

Abstract: An exemplary group ticket for a Kerberos protocol includes a service ticket encrypted with a dynamic group key and a plurality of enveloped pairs where each pair includes a name associated with a member of a group and an encrypted the dynamic group key for decryption by a key possessed by the member of the group where decryption of an encrypted dynamic group key allows for decryption of the service ticket. Other exemplary methods, systems, etc., are also disclosed.

Abstract: Sharing resources on a network include, for example, a domain controller hierarchy scheme, which is used in some implementations to organize and share both secure and non-secure resources in an efficient manner. Using authentication information can be used to architect a trustworthy system to divulging sensitive client data (such as user/computer passwords) to a host system. The sensitive client data can be released to the host system when a client establishes a relationship having a degree of trust with the host.