Abstract: The disclosed technology is generally directed to web authentication. In one example of the technology, authentication of a broker is obtained with an identity provider. Obtaining the authentication includes at least communication between the broker and a top-level frame and communication between the broker and the identity provider. The broker is executing in a descendant frame of the top-level frame. The top-level frame and the broker are hosted on different domains. At the broker, from an embedded application that is executing on another descendant frame of the top-level frame, a token request is received. Via the broker, a token is requested from the identity provider. The token is associated with an authorization of secure delegated remote access of at least one resource by the embedded application. At the broker, from the identity provider, the token is received. Via the broker, the token is provided to the embedded application.

Abstract: The disclosed technology is generally directed to web authentication. In one example of the technology, authentication of a broker with an identity provider is initiated. The broker is a first application that is executing in a top-level frame. At the broker, from a second application that is executing on a first descendent frame that is a descendant frame of the top-level frame, a token request is received. Via the broker, a first token is requested from the identity provider on behalf of the second application. The first token is associated with an authorization of secure delegated remote access of at least one resource by the second application. At the broker, from the identity provider, the first token is received. Via the broker, the first token is provided to the second application.

Abstract: The disclosed technology is generally directed to web authentication. In one example of the technology, authentication of a broker is obtained with an identity provider. Obtaining the authentication includes at least communication between the broker and a top-level frame and communication between the broker and the identity provider. The broker is executing in a descendant frame of the top-level frame. The top-level frame and the broker are hosted on different domains. At the broker, from an embedded application that is executing on another descendant frame of the top-level frame, a token request is received. Via the broker, a token is requested from the identity provider. The token is associated with an authorization of secure delegated remote access of at least one resource by the embedded application. At the broker, from the identity provider, the token is received. Via the broker, the token is provided to the embedded application.

Abstract: The disclosed technology is generally directed to web authentication. In one example of the technology, authentication of a broker with an identity provider is initiated. The broker is a first application that is executing in a top-level frame. At the broker, from a second application that is executing on a first descendent frame that is a descendant frame of the top-level frame, a token request is received. Via the broker, a first token is requested from the identity provider on behalf of the second application. The first token is associated with an authorization of secure delegated remote access of at least one resource by the second application. At the broker, from the identity provider, the first token is received. Via the broker, the first token is provided to the second application.

Abstract: Authentic remote presence for a user located at a source computer is established at a target computer without requiring transmission of the user password from the source computer to the target computer, and without requiring that the user be previously credentialed at the target. The presence established at the target computer will be recognized by a security domain identity provider as authentic, allowing the user to work remotely on the source computer as if the user was physically present at the target computer even when the source and target are miles apart. The remote access presence may be bound to the particular source and target computers, such that the presence credentials can only be used for remote access from the source through the target into the security domain. The remote access functionality will work with a wide variety of operating systems, on both desktop and mobile platforms.

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: An LDE authentication system is provided for granting to an LDE device access to a resource of a resource provider. In accordance with the LDE authentication system, an LDE device sends to the resource provider a request to access the resource. The LDE device receives an indication sent by the resource provider to authenticate the resource provider using an identity provider. A non-LDE device sends to the identity provider credentials for use in authentication and receives an authentication code sent by the identity provider that indicates successful authentication by the identity provider. The LDE device receives the authentication code that was received by the non-LDE device. The LDE device sends to the identity provider the authentication code and receives an authentication token sent by the identity provider in response to receiving the authentication code. The LDE device sends to the resource provider the authentication token and accesses the resource.

Abstract: Authenticating issues involving the re-authenticating of a first device that was previously authenticated are resolved by use of a second device which receives a notification of the failed authentication. The second device sends a response to the notification which is operable to facilitate re-authentication of the primary device and without requiring the user to provide credentials at the first device prior to obtaining the re-authentication at the primary device and/or without requiring the primary device to obtain a code to be entered into the secondary device and/or prior to the primary device being notified of a failure condition associated with the primary device.

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: 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: Providing access to a cloud service includes a system receiving an application request to access a cloud service. In response, the system sends an identity provider (IP) a token request, comprising an application identifier (ID), an operating system (OS) cloud credential associated with login credentials of a user of an OS hosting the application, and a cloud service ID of the cloud service. Based on sending the token request, and on the IP authenticating the user and verifying the application ID is valid, the system receives a token from the IP. The token, which is signed with an IP signature, comprises the cloud service ID, the application ID, and a user assigned ID associated with the cloud service. The system provides the token to the application for submission to a cloud service provider for access, and obtains cloud service access based on the cloud service provider validating the IP signature.

Abstract: Authenticating issues involving the re-authenticating of a first device that was previously authenticated are resolved by use of a second device which receives a notification of the failed authentication. The second device sends a response to the notification which is operable to facilitate re-authentication of the primary device and without requiring the user to provide credentials at the first device prior to obtaining the re-authentication at the primary device and/or without requiring the primary device to obtain a code to be entered into the secondary device and/or prior to the primary device being notified of a failure condition associated with the primary device.

Abstract: One or more techniques and/or systems are provided for obtaining access to a cloud service. In particular, a user may log into a client device using an operating system (OS) cloud login ID. The user may access cloud services (e.g., a music streaming service, a data storage service, etc.) through applications executing on the client device using merely the OS cloud login ID without providing additional login credentials specific to the cloud services. A client side application may request a token to access a cloud service. The token may be generated by an identity provider based upon the identity provider verifying an application ID identifying the application, a cloud service ID identifying the cloud service and/or OS cloud credentials. In this way, the application may present the token to a cloud service provider for verification to gain access to the cloud service hosted by the cloud service provider.

Abstract: In one embodiment, a user device 110 may access a network service 122 using a secure cookie 300. A high trust process may create an authentication proof 360 using a secure key. The high trust process may provide a browsing token 310 and the authentication proof 360 to a low trust process to send to an authentication service 124.

Abstract: One or more techniques and/or systems are provided for obtaining access to a cloud service. In particular, a user may log into a client device using an operating system (OS) cloud login ID. The user may access cloud services (e.g., a music streaming service, a data storage service, etc.) through applications executing on the client device using merely the OS cloud login ID without providing additional login credentials specific to the cloud services. A client side application may request a token to access a cloud service. The token may be generated by an identity provider based upon the identity provider verifying an application ID identifying the application, a cloud service ID identifying the cloud service and/or OS cloud credentials. In this way, the application may present the token to a cloud service provider for verification to gain access to the cloud service hosted by the cloud service provider.

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: In one embodiment, a user device 110 may access a network service 122 using a secure cookie 300. A high trust process may create an authentication proof 360 using a secure key. The high trust process may provide a browsing token 310 and the authentication proof 360 to a low trust process to send to an authentication service 124.