US20120311689A1 - Redirection using token and value - Google Patents
Redirection using token and value Download PDFInfo
- Publication number
- US20120311689A1 US20120311689A1 US13/153,234 US201113153234A US2012311689A1 US 20120311689 A1 US20120311689 A1 US 20120311689A1 US 201113153234 A US201113153234 A US 201113153234A US 2012311689 A1 US2012311689 A1 US 2012311689A1
- Authority
- US
- United States
- Prior art keywords
- computing system
- nonce
- supporting
- cookie
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
Definitions
- a conventional three party protocol is in use.
- the three parties include the client, the server (also called the relying party), and an identity provider, each being computing systems.
- the server is termed a “relying party” because it relies on the authentication of the client performed by the identity provider.
- the client makes a service request to the relying party. Recognizing that the client is not authenticated yet, the relying party redirects the client to the identity provider.
- the identity provider authenticates the client, provides a security token to the client, and instructs the client to provide that security token back to the relying party.
- Those instructions are sometimes in the form of executable code that is automatically executed by the client causing the client to provide the security token to the relying party.
- the relying party uses the security token to determine that the identity provider has indeed authenticated the client.
- At least one embodiment described herein relates to the secure use of a supporting service computing system (e.g., an identity provider or claims provider) to facilitate a request from a client computing system (i.e., the “client”) to a relying party computing system (i.e., the “relying party”), where the relying party computing system relies on the supporting service computing system (i.e., “supporting entity”) to perform a supporting service (such as, for example authentication or claim providing).
- the client and the relying party interact, with embodiments directed towards the action of the client, and other embodiments directed towards the action of the relying party.
- the mechanisms described herein inhibit the feasibility of replay attacks.
- a “replay attack” is an attack whereby a malicious individual uses the request history (e.g., the browser history in the case of the client executing a browser) to re-access a web site that the individual has not previously authenticated to using a prior authentication of a legitimate user.
- the request history e.g., the browser history in the case of the client executing a browser
- the client submits a service request to a relying party, and is thereby redirected by the relying party to the supporting entity (such as an identity provider or a claims provider).
- the relying party also sends a cookie that includes a nonce, and also the nonce in a redirection context outside of the cookie (e.g., in a context string).
- a cookie is any structure that is returned to the relying party in subsequent requests
- a nonce is any value that is used only once between the client and the relying party at least within the valid time of the nonce.
- the client then communicates with the supporting entity to facilitate the supporting service, whereupon the supporting entity sends a validation token back to the client evidencing completion of the supporting service.
- the supporting party also sends the nonce back as part of the redirection context (e.g., in a context string).
- the client then sends a followup service request that includes the cookie, the nonce returned by the supporting entity, and the validation token to the relying party.
- the relying party may then use the validation token to determine that the supporting service has been performed, and may compare the nonce in the cookie with the nonce returned by the supporting entity. If there is a match, then the followup request is a valid request, and is not a replay request.
- FIG. 1 illustrates an example computing system that may be used to employ embodiments described herein;
- FIG. 2 illustrates a three party environment that includes a client that desires a service be performed, a relying party that performs the service, and a supporting party that performs a supporting service relied upon by the relying party before the relying party provides the desired service to the client;
- FIG. 3 illustrates a flowchart of a method for facilitating a service request through redirection while reducing the opportunity for performing a replay attack
- FIG. 4 schematically illustrates a structure of a response to a service request, the service request issued from the client to the relying party, but the response returned from the relying party to the client;
- FIG. 5 schematically illustrates a structure of a redirection request from a client to a supporting party
- FIG. 6 schematically illustrates a structure of a response to a redirection request, the response issued from the supporting party to the client;
- FIG. 7 schematically illustrates a structure of a followup service request from the client to the relying party.
- FIG. 8 illustrates a flowchart of a method performed by the relying party to determine whether the followup service request is a replay attack.
- a client is redirected to a supporting entity (such as an identity or claims provider) when submitting a request initially to a relying party computing system.
- the relying party also returns a value (such as a nonce) that is in a redirection context such that the client submits the value to the supporting entity, whereupon that value is returned by the supporting entity along with a security token upon completion of the supporting service.
- the client also receives a cookie containing the value (perhaps in encrypted and/or signed form) to the client.
- the client responds to the completion of the supporting service by sending a followup service request to the relying party, perhaps in response to executing code provided by the supporting entity.
- the cookie is also returned in that followup service request.
- the relying party may compare the nonce in the cookie with the nonce returned by the supporting entity to verify that the request is valid and not a replay request.
- Computing systems are now increasingly taking a wide variety of forms.
- Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, or even devices that have not conventionally been considered a computing system.
- the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by the processor.
- the memory may take any form and may depend on the nature and form of the computing system.
- a computing system may be distributed over a network environment and may include multiple constituent computing systems.
- a computing system 100 typically includes at least one processing unit 102 and memory 104 .
- the memory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two.
- the term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.
- the term “module” or “component” can refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads).
- embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions.
- An example of such an operation involves the manipulation of data.
- the computer-executable instructions (and the manipulated data) may be stored in the memory 104 of the computing system 100 .
- Computing system 100 may also contain communication channels 108 that allow the computing system 100 to communicate with other message processors over, for example, network 110 .
- the computing system may also include a display 112 that may display one or more user interfaces that a user of the computing system may interface with.
- Embodiments described herein may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below.
- Embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures.
- Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system.
- Computer-readable media that store computer-executable instructions are physical storage media.
- Computer-readable media that carry computer-executable instructions are transmission media.
- embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.
- Computer storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
- a “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices.
- a network or another communications connection can include a network and/or data links which can be used to carry or desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
- program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa).
- computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system.
- a network interface module e.g., a “NIC”
- NIC network interface module
- computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
- the computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.
- the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like.
- the invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.
- program modules may be located in both local and remote memory storage devices.
- FIG. 2 illustrates a three party environment 200 that includes a client computing system (hereinafter “client”) 201 , a relying party computing system (hereinafter “relying party”) 202 , and a supporting party computing system (hereinafter “supporting party” or “supporting entity”) 203 .
- client computing system
- relying party a relying party computing system
- supporting party supporting party computing system
- Each of the client 201 , the replying party 202 , and the supporting entity 203 may be, for example, structured as described above for the computing system 100 of FIG. 1 .
- the client 201 includes a browser 204 that may initiate a service request upon navigation to a network site (such as a web site) hosted by the relying party 202 .
- network site such as a web site
- the client 201 initiates a service request (hereinafter also referred to as “the original service request”) to perform a service (hereinafter also referred to as the “primary service”) to the relying party 202 .
- the relying party 201 performs the primary service, but only after the client 201 interacts with the supporting party 203 to have a supporting service performed. This may be accomplished by having the relying party 202 redirect the client 201 to the supporting party 203 in response to the original service request.
- client “relying party” and “supporting party” with respect to computing system 201 , 202 , and 203 , respectively, are intended to be descriptive of the function of the computing system only with respect to the method 300 of FIG. 3 .
- these computing system 201 through 203 may not take on different functionalities in other contexts.
- the client 201 may also a relying party or a supporting party in other contexts.
- the relying party 202 may also be a client or a supporting party in other contexts.
- the supporting party 203 may also be a client or a relying party in other contents.
- the supporting party 203 may require the supporting services of yet another supporting party before the supporting party 203 performs the supporting service for the client 201 .
- the supporting party 203 may redirect the client 201 yet again to another supporting party (not shown).
- the method 300 of FIG. 3 may be performed recursively for two or more levels of redirection.
- a single level of redirection is described with respect to FIG. 2 .
- redirection is not a new concept.
- the principles described herein use the principles of redirection in a unique way to eliminate or reduce the possibility of replay attacks.
- a replay attack is a mechanism whereby the browser history may be used to replay a previously-made request to a relying party. In the previously made request, the supporting service was performed (such as authentication). The principles described herein allow the relying party to distinguish the previously made request from the replay of the request.
- the various arrows 211 through 216 are illustrated in FIG. 2 to show various interactions between the client 201 , the relying party 202 , and the supporting party 203 .
- the sequence of interactions is generally in the order shown, with the communication represented by arrow 211 being first, the communication represented by arrow 212 being second, or so forth, concluding with the communication represented by the arrow 216 .
- FIG. 3 illustrates a flowchart of a method 300 for facilitating a service request through redirection while reducing the opportunity for performing a replay attack.
- the method 300 will be described with frequent reference to FIG. 2 , and will help to further describe in further detail the flow (represented by arrows 211 through 216 ) of communication in the environment 200 .
- some of the acts performed in the method 300 are performed by the client 201 and are included in the left column of FIG. 3 under the heading “CLIENT”. Others of the acts are performed by the relying party 202 and are included in the right column of FIG. 3 under the heading “RELYING PARTY”.
- the method 300 is initiated upon the client 201 submitting a service request to the relying party 202 (act 311 ).
- the relying party 202 then receives the service request (act 312 ).
- This transmission is represented in FIG. 2 with arrow 211 .
- the service request could be any service request for a service offered by the relying party 201 . While the principles described herein do not exclude the possibility that the relying party 202 may sometimes be able to perform the primary service without requiring a supporting service, in the context of FIGS. 2 and 3 , the relying party 201 determines that client is to first obtain supporting service from a supporting party computing system before the service request is to be honored (act 322 ).
- the supporting service may be authentication or other identity providing service, and the supporting party may be an identity provider.
- the relying party 202 needs to determine whether some claims are true (e.g., payment has been made, the user of the client has government clearance, the user has a valid driver's license, the user has health insurance, the user is a relative of an authorized user and so forth), the supporting service would be the providing of a claim regarding the user, and the supporting party would be a claims provider.
- the relying party 202 In order for the relying party 202 to have the client 201 interact with the supporting party 203 to having the supporting service performed, the relying party transmits a response to the service request to the client 201 (act 323 ). The client 201 then receives the response to the service request (act 312 ). This transmission is represented in FIG. 2 by arrow 212 .
- FIG. 4 schematically shows the response 400 in which at least some of the content of the response is illustrated.
- the response 400 includes a cookie 410 .
- a cookie is a data structure that when returned by the relying party is stored on the client, and is correlated with that relying party. While the term is typically used in the context of the application being a browser, the term “cookie” as used herein is broader in that it is defined as any structure that is returned to the relying party in a subsequent service request. Thus, whenever a subsequent request is made to the relying party, unless the cookie has been deleted in the interim, that cookie will be returned to the relying party, allowing the relying party access to the cookie contents.
- the cookie 410 includes a “nonce” 411 . In this description and in the claims, a “nonce” is a value that is used only once between the client and the relying party at least within the valid time of the nonce.
- the response also includes a nonce 421 in a redirection context 420 .
- the redirection context 420 is interpretable by the client 201 , such that when the client 201 submits the redirection request to the supporting party 203 , the client 201 includes the nonce 421 in a particular context. That particular context likewise causes the supporting party to return the nonce in a particular context that forces the client to yet again include the nonce when submitting the followup service request to the relying party.
- the nonce could be included in a context string.
- the context string is a mechanism by which the relying party may basically echo back the contents of the context string from the supporting party through the client.
- the relying party 203 itself creates the context string, which is included by the client 201 in the redirection requested to the supporting party 202 , whereupon the supporting party 202 echoes back the context string to the client 201 in the response to the redirection request.
- the nonce 411 in the cookie 410 is correlated to the nonce 421 in the redirection context 420 .
- the nonce 411 in the cookie 410 may match the nonce 421 in the redirection context 420 . Accordingly, when the cookie 420 and the nonce 421 are returned, the relying party may expect the nonces 411 and 421 to match, and if they do not, the relying party may determine that something has gone wrong with the normal process.
- the client 201 responds to the response 400 by constructing a redirection request to the supporting party to perform a supporting service (act 313 ), and transmits that redirection request to the supporting party (act 314 ).
- the redirection instruction 430 may an indication of the address of the supporting party with a query string that specifies the context string.
- FIG. 5 shows the redirection request 500 and at least some of its contents.
- the redirection request 500 includes the nonce 421 .
- the client 201 included the nonce 421 in the redirection request because the relying party included the nonce 421 in the redirection context 420 in the response 400 .
- the nonce 421 is included in a particular context 520 in the redirection context that will cause the supporting party to return the nonce 421 back to the client in the response to the redirection request.
- the client transmits the redirection request to the supporting party (see arrow 213 in FIG. 2 ).
- the client may also perform other interaction with the supporting party (see arrow 214 in FIG. 2 ) (act 315 ) to facilitating the supporting service.
- the supporting party may prompt the user of the client for credentials, and the user may provide such credentials through the client.
- the supporting party Upon completing the supporting service, the supporting party then provides a response to the redirection request to the client (represented by arrow 215 ) (act 316 ).
- FIG. 6 illustrates a response 600 to the redirection request, along with at least some of its contents.
- the nonce 421 is returned in the response 600 , since the nonce 421 was included in the redirection request 500 in the context 520 .
- the nonce 421 is included in a context 620 and a redirection instruction 630 that will cause the client to include the nonce in a followup service request.
- the response 600 also includes a validation token 601 that would be interpretable by the relying party to give assurance that the supporting service has been performed.
- the redirection instruction 630 may be executable code that is automatically executed by the client computing system to cause the client computing system to construct and transmit (act 317 ) a followup service request (such as that described with respect to FIG. 7 ) to the relying party (see arrow 216 in FIG. 2 ).
- FIG. 7 illustrates the followup service request 700 and at least some of its contents.
- the followup service request 700 in includes the validation token 601 and the nonce 421 that was returned by the supporting party. However, the followup service request 700 also includes the cookie 410 that was provided by the relying party to the client in response to the original service request. Recall that that cookie 410 includes the nonce 411 . The nonce 411 may have been signed and/or encrypted within the cookie 410 to avoid tampering. The relying party then receives the followup service request from the client (act 324 ).
- the relying party determines whether the supporting service was completed by the supporting party computing system by evaluating the validation token in the followup service request (act 325 ). For instance, if the supporting party were an identity provider, the relying party may authenticate the client or its user without actually having to perform the authentication. However, the relying party may also determine whether the followup service request is a replay of the prior service request (act 326 ) by evaluating the nonces in the followup service requests.
- FIG. 8 illustrates a flowchart of a method 800 performed by the relying party to determine whether the followup service request is a replay attack.
- the method 800 is one example of act 326 of FIG. 3 .
- the relying party first determines whether or not the cookie 410 is even present in the followup service request (decision block 801 ). If the cookie 410 is not present (No in decision block 801 ), then the cookie has been deleted at the client, or otherwise is prevented from being included in the followup service request. This is symptomatic of preparations made for a replay attack, or at the very least removes the ability to compare the nonces 411 and 421 , which is the basis for determine whether a replay attack is occurring.
- the client is instructed to delete the cookie 410 (act 803 ) from its stores so that it is no longer used in further followup service requests to the relying party.
- the relying party extracts the nonce 411 from the cookie 410 . This may involve decrypting the nonce and/or confirming through the signature of the nonce that the nonce 411 has not been tampered with since the relying party provided the nonce 411 to the client. The relying party then compares the nonce 411 from the cookie 410 with the nonce 421 returned by the supporting party.
- the nonce 411 is determined to “match” the nonce 421 (“Yes” in decision block 804 ) if they are exactly equal values.
- the nonce 411 may have any other correlation with the nonce 421 that is determined to be the expected “match”.
- the relying party can determine that the followup service request is in direct response to the client having interacted with the supporting party in response to the redirection instruction.
- a replay attack is not detected (act 805 ). However, if the nonces do not match (No in decision block 804 ), then this may be a replay attack (act 802 ). For instance, the cookie returned in the followup service request may be from a much earlier redirection request corresponding to a service request that was long ago completed. If the unauthorized user then tried to use the browser history to replay the followup service request, the cookie would either not be present, or the nonce would not match.
- the principles described herein provide a more secure mechanism for avoiding replay attacks in the context in which a relying party redirects a client to a supporting party (such as an identity provider) for purposes of performing a supporting service (such as authentication).
- a supporting party such as an identity provider
- a supporting service such as authentication
- the relying party 202 may cause a cookie (i.e., a “second cookie” to distinguish this cookie from the cookie 410 ) to be placed on the client computing system.
- the client 201 may make a request to the relying party 202 and the relying party will honor that request at least during a particular duration (e.g., during the time of the session), without redirecting the client 201 to the supporting party 203 .
- this second cookie may be used in a single sign-on (SSO) experience in which the cookie may also be recognized by other relying parties other than the relying party 202 .
- SSO single sign-on
- relying party 202 is called “relaying party A”. Now suppose that relying parties A and B can both write cookies that the other can read. If relying party A has already interacted indirectly (through the client) with the supporting party in accordance with the method 300 resulting in the creation of the mutually-respected second cookie, replying party B does not have to repeat the interaction with the supporting party, but instead just recognizes the mutually-respected second cookie.
Abstract
Description
- In order to properly authenticate a client to a server, a conventional three party protocol is in use. The three parties include the client, the server (also called the relying party), and an identity provider, each being computing systems. The server is termed a “relying party” because it relies on the authentication of the client performed by the identity provider.
- In this protocol, the client makes a service request to the relying party. Recognizing that the client is not authenticated yet, the relying party redirects the client to the identity provider. The identity provider authenticates the client, provides a security token to the client, and instructs the client to provide that security token back to the relying party. Those instructions are sometimes in the form of executable code that is automatically executed by the client causing the client to provide the security token to the relying party. The relying party then uses the security token to determine that the identity provider has indeed authenticated the client.
- At least one embodiment described herein relates to the secure use of a supporting service computing system (e.g., an identity provider or claims provider) to facilitate a request from a client computing system (i.e., the “client”) to a relying party computing system (i.e., the “relying party”), where the relying party computing system relies on the supporting service computing system (i.e., “supporting entity”) to perform a supporting service (such as, for example authentication or claim providing). The client and the relying party interact, with embodiments directed towards the action of the client, and other embodiments directed towards the action of the relying party. The mechanisms described herein inhibit the feasibility of replay attacks. A “replay attack” is an attack whereby a malicious individual uses the request history (e.g., the browser history in the case of the client executing a browser) to re-access a web site that the individual has not previously authenticated to using a prior authentication of a legitimate user.
- In one embodiment, the client submits a service request to a relying party, and is thereby redirected by the relying party to the supporting entity (such as an identity provider or a claims provider). In the redirection reply, the relying party also sends a cookie that includes a nonce, and also the nonce in a redirection context outside of the cookie (e.g., in a context string). In this context, a cookie is any structure that is returned to the relying party in subsequent requests, and a nonce is any value that is used only once between the client and the relying party at least within the valid time of the nonce. The client then communicates with the supporting entity to facilitate the supporting service, whereupon the supporting entity sends a validation token back to the client evidencing completion of the supporting service. The supporting party also sends the nonce back as part of the redirection context (e.g., in a context string). The client then sends a followup service request that includes the cookie, the nonce returned by the supporting entity, and the validation token to the relying party. The relying party may then use the validation token to determine that the supporting service has been performed, and may compare the nonce in the cookie with the nonce returned by the supporting entity. If there is a match, then the followup request is a valid request, and is not a replay request.
- This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
- In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of various embodiments will be rendered by reference to the appended drawings. Understanding that these drawings depict only sample embodiments and are not therefore to be considered to be limiting of the scope of the invention, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
-
FIG. 1 illustrates an example computing system that may be used to employ embodiments described herein; -
FIG. 2 illustrates a three party environment that includes a client that desires a service be performed, a relying party that performs the service, and a supporting party that performs a supporting service relied upon by the relying party before the relying party provides the desired service to the client; -
FIG. 3 illustrates a flowchart of a method for facilitating a service request through redirection while reducing the opportunity for performing a replay attack; -
FIG. 4 schematically illustrates a structure of a response to a service request, the service request issued from the client to the relying party, but the response returned from the relying party to the client; -
FIG. 5 schematically illustrates a structure of a redirection request from a client to a supporting party; -
FIG. 6 schematically illustrates a structure of a response to a redirection request, the response issued from the supporting party to the client; -
FIG. 7 schematically illustrates a structure of a followup service request from the client to the relying party; and -
FIG. 8 illustrates a flowchart of a method performed by the relying party to determine whether the followup service request is a replay attack. - In accordance with embodiments described herein, a client is redirected to a supporting entity (such as an identity or claims provider) when submitting a request initially to a relying party computing system. The relying party also returns a value (such as a nonce) that is in a redirection context such that the client submits the value to the supporting entity, whereupon that value is returned by the supporting entity along with a security token upon completion of the supporting service. The client also receives a cookie containing the value (perhaps in encrypted and/or signed form) to the client. The client responds to the completion of the supporting service by sending a followup service request to the relying party, perhaps in response to executing code provided by the supporting entity. The cookie is also returned in that followup service request. The relying party may compare the nonce in the cookie with the nonce returned by the supporting entity to verify that the request is valid and not a replay request. First, some introductory discussion regarding computing systems will be described with respect to
FIG. 1 . Then, the embodiments of the secure redirection will be described with respect toFIGS. 2 through 8 . - First, introductory discussion regarding computing systems is described with respect to
FIG. 1 . Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, or even devices that have not conventionally been considered a computing system. In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by the processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems. - As illustrated in
FIG. 1 , in its most basic configuration, acomputing system 100 typically includes at least oneprocessing unit 102 andmemory 104. Thememory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well. As used herein, the term “module” or “component” can refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). - In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors of the associated computing system that performs the act direct the operation of the computing system in response to having executed computer-executable instructions. An example of such an operation involves the manipulation of data. The computer-executable instructions (and the manipulated data) may be stored in the
memory 104 of thecomputing system 100.Computing system 100 may also containcommunication channels 108 that allow thecomputing system 100 to communicate with other message processors over, for example,network 110. The computing system may also include adisplay 112 that may display one or more user interfaces that a user of the computing system may interface with. - Embodiments described herein may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.
- Computer storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
- A “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry or desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
- Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
- Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
-
FIG. 2 illustrates a threeparty environment 200 that includes a client computing system (hereinafter “client”) 201, a relying party computing system (hereinafter “relying party”) 202, and a supporting party computing system (hereinafter “supporting party” or “supporting entity”) 203. Each of theclient 201, the replyingparty 202, and the supportingentity 203 may be, for example, structured as described above for thecomputing system 100 ofFIG. 1 . Optionally, theclient 201 includes abrowser 204 that may initiate a service request upon navigation to a network site (such as a web site) hosted by the relyingparty 202. - The
client 201 initiates a service request (hereinafter also referred to as “the original service request”) to perform a service (hereinafter also referred to as the “primary service”) to the relyingparty 202. The relyingparty 201 performs the primary service, but only after theclient 201 interacts with the supportingparty 203 to have a supporting service performed. This may be accomplished by having the relyingparty 202 redirect theclient 201 to the supportingparty 203 in response to the original service request. - The terms “client”, “relying party” and “supporting party” with respect to
computing system method 300 ofFIG. 3 . There is nothing to say that thesecomputing system 201 through 203 may not take on different functionalities in other contexts. For instance, theclient 201 may also a relying party or a supporting party in other contexts. The relyingparty 202 may also be a client or a supporting party in other contexts. The supportingparty 203 may also be a client or a relying party in other contents. For instance, the supportingparty 203 may require the supporting services of yet another supporting party before the supportingparty 203 performs the supporting service for theclient 201. Thus, the supportingparty 203 may redirect theclient 201 yet again to another supporting party (not shown). Thus, themethod 300 ofFIG. 3 may be performed recursively for two or more levels of redirection. However, to keep the principles described herein easier to read and understand, a single level of redirection is described with respect toFIG. 2 . - Of course, redirection is not a new concept. However, the principles described herein use the principles of redirection in a unique way to eliminate or reduce the possibility of replay attacks. A replay attack is a mechanism whereby the browser history may be used to replay a previously-made request to a relying party. In the previously made request, the supporting service was performed (such as authentication). The principles described herein allow the relying party to distinguish the previously made request from the replay of the request.
- The
various arrows 211 through 216 are illustrated inFIG. 2 to show various interactions between theclient 201, the relyingparty 202, and the supportingparty 203. The sequence of interactions is generally in the order shown, with the communication represented byarrow 211 being first, the communication represented byarrow 212 being second, or so forth, concluding with the communication represented by thearrow 216. -
FIG. 3 illustrates a flowchart of amethod 300 for facilitating a service request through redirection while reducing the opportunity for performing a replay attack. Themethod 300 will be described with frequent reference toFIG. 2 , and will help to further describe in further detail the flow (represented byarrows 211 through 216) of communication in theenvironment 200. Referring toFIG. 3 , some of the acts performed in themethod 300 are performed by theclient 201 and are included in the left column ofFIG. 3 under the heading “CLIENT”. Others of the acts are performed by the relyingparty 202 and are included in the right column ofFIG. 3 under the heading “RELYING PARTY”. - The
method 300 is initiated upon theclient 201 submitting a service request to the relying party 202 (act 311). The relyingparty 202 then receives the service request (act 312). This transmission is represented inFIG. 2 witharrow 211. The service request could be any service request for a service offered by the relyingparty 201. While the principles described herein do not exclude the possibility that the relyingparty 202 may sometimes be able to perform the primary service without requiring a supporting service, in the context ofFIGS. 2 and 3 , the relyingparty 201 determines that client is to first obtain supporting service from a supporting party computing system before the service request is to be honored (act 322). - As an example, suppose that the relying
party 202 requires authentication of theclient 201 before performing the primary service. In that case, the supporting service may be authentication or other identity providing service, and the supporting party may be an identity provider. As another example, suppose that the relyingparty 202 needs to determine whether some claims are true (e.g., payment has been made, the user of the client has government clearance, the user has a valid driver's license, the user has health insurance, the user is a relative of an authorized user and so forth), the supporting service would be the providing of a claim regarding the user, and the supporting party would be a claims provider. - In order for the relying
party 202 to have theclient 201 interact with the supportingparty 203 to having the supporting service performed, the relying party transmits a response to the service request to the client 201 (act 323). Theclient 201 then receives the response to the service request (act 312). This transmission is represented inFIG. 2 byarrow 212. -
FIG. 4 schematically shows theresponse 400 in which at least some of the content of the response is illustrated. Theresponse 400 includes acookie 410. A cookie is a data structure that when returned by the relying party is stored on the client, and is correlated with that relying party. While the term is typically used in the context of the application being a browser, the term “cookie” as used herein is broader in that it is defined as any structure that is returned to the relying party in a subsequent service request. Thus, whenever a subsequent request is made to the relying party, unless the cookie has been deleted in the interim, that cookie will be returned to the relying party, allowing the relying party access to the cookie contents. In this case, thecookie 410 includes a “nonce” 411. In this description and in the claims, a “nonce” is a value that is used only once between the client and the relying party at least within the valid time of the nonce. - Referring again to
FIG. 4 , the response also includes a nonce 421 in aredirection context 420. Theredirection context 420 is interpretable by theclient 201, such that when theclient 201 submits the redirection request to the supportingparty 203, theclient 201 includes the nonce 421 in a particular context. That particular context likewise causes the supporting party to return the nonce in a particular context that forces the client to yet again include the nonce when submitting the followup service request to the relying party. As an example, the nonce could be included in a context string. The context string is a mechanism by which the relying party may basically echo back the contents of the context string from the supporting party through the client. In one embodiment, the relyingparty 203 itself creates the context string, which is included by theclient 201 in the redirection requested to the supportingparty 202, whereupon the supportingparty 202 echoes back the context string to theclient 201 in the response to the redirection request. - The nonce 411 in the
cookie 410 is correlated to the nonce 421 in theredirection context 420. For instance, the nonce 411 in thecookie 410 may match the nonce 421 in theredirection context 420. Accordingly, when thecookie 420 and the nonce 421 are returned, the relying party may expect thenonces - Since the
response 400 also includes aredirection instruction 430, theclient 201 responds to theresponse 400 by constructing a redirection request to the supporting party to perform a supporting service (act 313), and transmits that redirection request to the supporting party (act 314). As an example, in the context of thebrowser 204, theredirection instruction 430 may an indication of the address of the supporting party with a query string that specifies the context string.FIG. 5 shows theredirection request 500 and at least some of its contents. Theredirection request 500 includes thenonce 421. Theclient 201 included the nonce 421 in the redirection request because the relying party included the nonce 421 in theredirection context 420 in theresponse 400. The nonce 421 is included in aparticular context 520 in the redirection context that will cause the supporting party to return the nonce 421 back to the client in the response to the redirection request. - The client then transmits the redirection request to the supporting party (see
arrow 213 inFIG. 2 ). Optionally, the client may also perform other interaction with the supporting party (seearrow 214 inFIG. 2 ) (act 315) to facilitating the supporting service. For instance, if the supporting party were an identity service provider, the supporting party may prompt the user of the client for credentials, and the user may provide such credentials through the client. Upon completing the supporting service, the supporting party then provides a response to the redirection request to the client (represented by arrow 215) (act 316). -
FIG. 6 illustrates aresponse 600 to the redirection request, along with at least some of its contents. The nonce 421 is returned in theresponse 600, since the nonce 421 was included in theredirection request 500 in thecontext 520. Here, thenonce 421 is included in acontext 620 and aredirection instruction 630 that will cause the client to include the nonce in a followup service request. Theresponse 600 also includes avalidation token 601 that would be interpretable by the relying party to give assurance that the supporting service has been performed. As an example, theredirection instruction 630 may be executable code that is automatically executed by the client computing system to cause the client computing system to construct and transmit (act 317) a followup service request (such as that described with respect toFIG. 7 ) to the relying party (seearrow 216 inFIG. 2 ). -
FIG. 7 illustrates thefollowup service request 700 and at least some of its contents. Thefollowup service request 700 in includes thevalidation token 601 and the nonce 421 that was returned by the supporting party. However, thefollowup service request 700 also includes thecookie 410 that was provided by the relying party to the client in response to the original service request. Recall that thatcookie 410 includes thenonce 411. The nonce 411 may have been signed and/or encrypted within thecookie 410 to avoid tampering. The relying party then receives the followup service request from the client (act 324). - Given the contents of the followup service request, the relying party determines whether the supporting service was completed by the supporting party computing system by evaluating the validation token in the followup service request (act 325). For instance, if the supporting party were an identity provider, the relying party may authenticate the client or its user without actually having to perform the authentication. However, the relying party may also determine whether the followup service request is a replay of the prior service request (act 326) by evaluating the nonces in the followup service requests.
-
FIG. 8 illustrates a flowchart of amethod 800 performed by the relying party to determine whether the followup service request is a replay attack. Themethod 800 is one example ofact 326 ofFIG. 3 . The relying party first determines whether or not thecookie 410 is even present in the followup service request (decision block 801). If thecookie 410 is not present (No in decision block 801), then the cookie has been deleted at the client, or otherwise is prevented from being included in the followup service request. This is symptomatic of preparations made for a replay attack, or at the very least removes the ability to compare thenonces cookie 410 is present in the followup service request (No in decision block 801), then there may be a replay attack occurring (act 802). One appropriate response to that situation would be to deny the followup service request, or perform themethod 300 again, which would require the requestor to interface with the supporting party to again perform the supporting service. - If there is a
cookie 410 in the followup service request (Yes in decision block 801), then the client is instructed to delete the cookie 410 (act 803) from its stores so that it is no longer used in further followup service requests to the relying party. Furthermore, the relying party extracts the nonce 411 from thecookie 410. This may involve decrypting the nonce and/or confirming through the signature of the nonce that the nonce 411 has not been tampered with since the relying party provided the nonce 411 to the client. The relying party then compares the nonce 411 from thecookie 410 with the nonce 421 returned by the supporting party. In the most straightforward implementation, thenonce 411 is determined to “match” the nonce 421 (“Yes” in decision block 804) if they are exactly equal values. However, the nonce 411 may have any other correlation with the nonce 421 that is determined to be the expected “match”. By comparing thenonces - If there is a match in the nonces (Yes in decision block 804), then a replay attack is not detected (act 805). However, if the nonces do not match (No in decision block 804), then this may be a replay attack (act 802). For instance, the cookie returned in the followup service request may be from a much earlier redirection request corresponding to a service request that was long ago completed. If the unauthorized user then tried to use the browser history to replay the followup service request, the cookie would either not be present, or the nonce would not match.
- Accordingly the principles described herein provide a more secure mechanism for avoiding replay attacks in the context in which a relying party redirects a client to a supporting party (such as an identity provider) for purposes of performing a supporting service (such as authentication).
- In one embodiment, once the relying
party 202 proves that the followup service request is not a replay attack, the relyingparty 202 may cause a cookie (i.e., a “second cookie” to distinguish this cookie from the cookie 410) to be placed on the client computing system. Theclient 201 may make a request to the relyingparty 202 and the relying party will honor that request at least during a particular duration (e.g., during the time of the session), without redirecting theclient 201 to the supportingparty 203. In some embodiments, this second cookie may be used in a single sign-on (SSO) experience in which the cookie may also be recognized by other relying parties other than the relyingparty 202. For instance, suppose that relyingparty 202 is called “relaying party A”. Now suppose that relying parties A and B can both write cookies that the other can read. If relying party A has already interacted indirectly (through the client) with the supporting party in accordance with themethod 300 resulting in the creation of the mutually-respected second cookie, replying party B does not have to repeat the interaction with the supporting party, but instead just recognizes the mutually-respected second cookie. - The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/153,234 US8661519B2 (en) | 2011-06-03 | 2011-06-03 | Redirection using token and value |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/153,234 US8661519B2 (en) | 2011-06-03 | 2011-06-03 | Redirection using token and value |
Publications (2)
Publication Number | Publication Date |
---|---|
US20120311689A1 true US20120311689A1 (en) | 2012-12-06 |
US8661519B2 US8661519B2 (en) | 2014-02-25 |
Family
ID=47262782
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/153,234 Active 2031-09-19 US8661519B2 (en) | 2011-06-03 | 2011-06-03 | Redirection using token and value |
Country Status (1)
Country | Link |
---|---|
US (1) | US8661519B2 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130275469A1 (en) * | 2012-04-17 | 2013-10-17 | Microsoft Corporation | Discovery of familiar claims providers |
US20140137248A1 (en) * | 2012-11-14 | 2014-05-15 | Damian Gajda | Client Token Storage for Cross-Site Request Forgery Protection |
US9444817B2 (en) | 2012-09-27 | 2016-09-13 | Microsoft Technology Licensing, Llc | Facilitating claim use by service providers |
US20160330220A1 (en) * | 2015-05-07 | 2016-11-10 | Cyber-Ark Software Ltd. | Systems and Methods for Detecting and Reacting to Malicious Activity in Computer Networks |
WO2017209758A1 (en) * | 2016-06-02 | 2017-12-07 | autoGraph, Inc. | Consumer and brand owner data management tools and consumer privacy tools |
US20180123782A1 (en) * | 2016-10-27 | 2018-05-03 | Motorola Solutions, Inc. | Method for secret origination service to distribute a shared secret |
US10348712B2 (en) * | 2016-02-26 | 2019-07-09 | Ricoh Company, Ltd. | Apparatus, authentication system, and authentication method |
US10540515B2 (en) | 2012-11-09 | 2020-01-21 | autoGraph, Inc. | Consumer and brand owner data management tools and consumer privacy tools |
EP4293544A1 (en) * | 2022-06-14 | 2023-12-20 | Citrix Systems Inc. | Bookmarking support for federated login pages |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040210771A1 (en) * | 1999-08-05 | 2004-10-21 | Sun Microsystems, Inc. | Log-on service providing credential level change without loss of session continuity |
US7197568B2 (en) * | 2002-03-27 | 2007-03-27 | International Business Machines Corporation | Secure cache of web session information using web browser cookies |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6199113B1 (en) | 1998-04-15 | 2001-03-06 | Sun Microsystems, Inc. | Apparatus and method for providing trusted network security |
US6421768B1 (en) | 1999-05-04 | 2002-07-16 | First Data Corporation | Method and system for authentication and single sign on using cryptographically assured cookies in a distributed computer environment |
US6668322B1 (en) | 1999-08-05 | 2003-12-23 | Sun Microsystems, Inc. | Access management system and method employing secure credentials |
CA2327078C (en) | 2000-11-30 | 2005-01-11 | Ibm Canada Limited-Ibm Canada Limitee | Secure session management and authentication for web sites |
US7644434B2 (en) | 2002-04-25 | 2010-01-05 | Applied Identity, Inc. | Computer security system |
US7240192B1 (en) | 2003-03-12 | 2007-07-03 | Microsoft Corporation | Combining a browser cache and cookies to improve the security of token-based authentication protocols |
US7676834B2 (en) | 2004-07-15 | 2010-03-09 | Anakam L.L.C. | System and method for blocking unauthorized network log in using stolen password |
-
2011
- 2011-06-03 US US13/153,234 patent/US8661519B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040210771A1 (en) * | 1999-08-05 | 2004-10-21 | Sun Microsystems, Inc. | Log-on service providing credential level change without loss of session continuity |
US7197568B2 (en) * | 2002-03-27 | 2007-03-27 | International Business Machines Corporation | Secure cache of web session information using web browser cookies |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130275469A1 (en) * | 2012-04-17 | 2013-10-17 | Microsoft Corporation | Discovery of familiar claims providers |
US20130276087A1 (en) * | 2012-04-17 | 2013-10-17 | Microsoft Corporation | Multifactor authentication |
US9571491B2 (en) * | 2012-04-17 | 2017-02-14 | Microsoft Technology Licensing, Llc | Discovery of familiar claims providers |
US8806652B2 (en) | 2012-04-17 | 2014-08-12 | Microsoft Corporation | Privacy from cloud operators |
US8973123B2 (en) * | 2012-04-17 | 2015-03-03 | Microsoft Technology Licensing, Llc | Multifactor authentication |
US9444817B2 (en) | 2012-09-27 | 2016-09-13 | Microsoft Technology Licensing, Llc | Facilitating claim use by service providers |
US10540515B2 (en) | 2012-11-09 | 2020-01-21 | autoGraph, Inc. | Consumer and brand owner data management tools and consumer privacy tools |
US9104838B2 (en) * | 2012-11-14 | 2015-08-11 | Google Inc. | Client token storage for cross-site request forgery protection |
US20140137248A1 (en) * | 2012-11-14 | 2014-05-15 | Damian Gajda | Client Token Storage for Cross-Site Request Forgery Protection |
US20160330220A1 (en) * | 2015-05-07 | 2016-11-10 | Cyber-Ark Software Ltd. | Systems and Methods for Detecting and Reacting to Malicious Activity in Computer Networks |
US10044726B2 (en) * | 2015-05-07 | 2018-08-07 | Cyberark Software Ltd. | Systems and methods for detecting and reacting to malicious activity in computer networks |
US10348712B2 (en) * | 2016-02-26 | 2019-07-09 | Ricoh Company, Ltd. | Apparatus, authentication system, and authentication method |
WO2017209758A1 (en) * | 2016-06-02 | 2017-12-07 | autoGraph, Inc. | Consumer and brand owner data management tools and consumer privacy tools |
US20180123782A1 (en) * | 2016-10-27 | 2018-05-03 | Motorola Solutions, Inc. | Method for secret origination service to distribute a shared secret |
EP4293544A1 (en) * | 2022-06-14 | 2023-12-20 | Citrix Systems Inc. | Bookmarking support for federated login pages |
Also Published As
Publication number | Publication date |
---|---|
US8661519B2 (en) | 2014-02-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8661519B2 (en) | Redirection using token and value | |
EP3500972B1 (en) | Protection feature for data stored at storage service | |
US8978115B2 (en) | Home realm discovery in mixed-mode federated realms | |
CN112136303B (en) | Secure delegation of refresh tokens for time-consuming operations | |
US9369286B2 (en) | System and methods for facilitating authentication of an electronic device accessing plurality of mobile applications | |
US8474019B2 (en) | Securing asynchronous client server transactions | |
US10225260B2 (en) | Enhanced authentication security | |
CN111262889A (en) | Authority authentication method, device, equipment and medium for cloud service | |
US10554643B2 (en) | Method and system to provide additional security mechanism for packaged web applications | |
US11895111B2 (en) | Systems and methods of application single sign on | |
US11356261B2 (en) | Apparatus and methods for secure access to remote content | |
US20210399897A1 (en) | Protection of online applications and webpages using a blockchain | |
CN102655496A (en) | Logging method, system and device | |
CN112202813B (en) | Network access method and device | |
US11949714B2 (en) | Cross-site request forgery protection | |
EP3036674B1 (en) | Proof of possession for web browser cookie based security tokens | |
US9787658B2 (en) | Login system based on server, login server, and verification method thereof | |
CN111988313A (en) | Data processing method, device, system and medium for block chain | |
Kandil et al. | Mobile agents' authentication using a proposed light Kerberos system | |
US11849041B2 (en) | Secure exchange of session tokens for claims-based tokens in an extensible system | |
CN114615070B (en) | Network security event capturing method and device based on trusted execution environment | |
US20230129631A1 (en) | Detecting and protecting against inconsistent use of cross-site request forgery mitigation features | |
US20240146724A1 (en) | Systems and methods of application single sign on | |
CN114090996A (en) | Multi-party system mutual trust authentication method and device | |
Ruhi Velasco | Web Authorization and authentication for single page applications (SPAs) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MICROSOFT CORPORATION, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KRON, PETER V.;REEL/FRAME:026419/0474 Effective date: 20110602 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034544/0001 Effective date: 20141014 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |