![](\"https://media-s3-us-east-1.ceros.com/editorial-content/images/2018/05/31/c5c224dc0fb2a058625073c470d70c3c/recaptcha-big.png?ver=1552286291?imageOpt=1&fit=bounds&width=1077\")
A basic example of a JavaScript event
\nEvents, in JavaScript, are occurrences that can trigger certain functionality, and can result in certain behaviour. A common example of an event, is a “click”, or a “hover”. You can set listeners to watch for these events that will trigger your desired functionality.
\nWhat is “propagation”?
\nPropagation refers to how events travel through the Document Object Model (DOM) tree. The DOM tree is the structure which contains parent/child/sibling elements in relation to each other. You can think of propagation as electricity running through a wire, until it reaches its destination. The event needs to pass through every node on the DOM until it reaches the end, or if it is forcibly stopped.
\nEvent Bubbling and Capturing
\nBubbling and Capturing are the two phases of propagation. In their simplest definitions, bubbling travels from the target to the root, and capturing travels from the root to the target. However, that doesn’t make much sense without first defining what a target and a root is.
\nThe target is the DOM node on which you click, or trigger with any other event.
\nFor example, a button with a click event would be the event target.
\nThe root is the highest-level parent of the target. This is usually the document, which is a parent of the , which is a (possibly distant) parent of your target element.
\nCapturing is not used nearly as commonly as bubbling, so our examples will revolve around the bubbling phase. As an option though, EventTarget.addEventListener() has an optional third parameter - which takes its argument as a boolean - which controls the phase of the propagation. The parameter is called useCapture, and passing true will cause the listener to be on the capturing phase. The default is false, which will apply it to the bubbling phase.
\nOnce you trigger the event, it will propagate up to the root, and it will trigger every single event handler which is associated with the same type. For example, if your button has a click event, during the bubbling phase, it will bubble up to the root, and trigger every click event along the way.
\nThis kind of behaviour might not sound desirable - and it often isn’t - but there’s an easy workaround...
\nEvent.stopPropagation()
\nThese two methods are used for solving the previously mentioned problem regarding event propagation. Calling Event.stopPropagation() will prevent further propagation through the DOM tree, and only run the event handler from which it was called.
\n<!--Try it-->function first() {\n console.log(1);\n}\nfunction second() {\n console.log(2);\n}\nvar button = document.getElementById("button");\nvar container = document.getElementById("container");\nbutton.addEventListener("click", first);\ncontainer.addEventListener("click", second);In this example, clicking the button will cause the console to print 1, 2. If we wanted to modify this so that only the button’s click event is triggered, we could use Event.stopPropagation() to immediately stop the event from bubbling to its parent.
\nfunction first(event) {\n event.stopPropagation();\n console.log(1);\n}This modification will allow the console to print 1, but it will end the event chain right away, preventing it from reaching 2.
\nHow does this differ from Event.stopImmediatePropagation()? When would you use either?
<!--Try it-->function first(event) {\n console.log(1);\n}\nfunction second() {\n console.log(2);\n}\nfunction third() {\n console.log(3);\n}\nvar button = document.getElementById("button");\nvar container = document.getElementById("container");\nbutton.addEventListener("click", first);\nbutton.addEventListener("click", second);\ncontainer.addEventListener("click", third);Let’s suppose we wanted to add a third function, which prints 3 to the console. In this scenario, we will also move the second function to also be on the button. We will apply third to the container now.
\nLong story short: we have two event handlers on the button, and clicking <div#container> will now print 3.
\nWhat will happen now? This will behave the same as before, and it will propagate through the DOM tree, and print 1, 2, 3, in that order.
\nHow does this tie in to Event.stopPropagation() and Event.stopImmediatePropagation()?
Adding Event.stopPropagation() to the first function, like so, will print 1, 2 to the console.
\nfunction first(event) {\n event.stopPropagation();\n console.log(1);\n}This is because Event.stopPropagation() will immediately prevent all click events on the parent from being triggered, but it does not stop any other event handlers from being called.
\nAs you can see in our example, our button has two click handlers, and it did stop the propagation to its parents. If you wanted to stop all event handlers after the first, that’s where Event.stopImmediatePropagation() comes in.
\nfunction first(event) {\n event.stopImmediatePropagation();\n console.log(1);\n}Now, the first function really will stop the parent click handlers, and all other click handlers. The console will now print just 1, whereas if we simply used Event.stopPropagation(), it would print 1, 2, and not including either would print 1, 2, 3 .
\n","frontmatter":{"date":"July 22, 2019","updated_date":null,"description":null,"title":"JavaScript Events: Bubbling, Capturing, and Propagation","tags":["JavaScript","JavaScript Events"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.3333333333333333,"src":"/static/ec578c09d831dd93165ad9409178344c/c0886/bubbles.png","srcSet":"/static/ec578c09d831dd93165ad9409178344c/69585/bubbles.png 200w,\n/static/ec578c09d831dd93165ad9409178344c/497c6/bubbles.png 400w,\n/static/ec578c09d831dd93165ad9409178344c/c0886/bubbles.png 772w","sizes":"(max-width: 772px) 100vw, 772px"}}},"author":{"id":"Greg Sakai","github":null,"avatar":null}}}},{"node":{"excerpt":"It is hard to write 100% holes-free code, no matter how hard you try. Sometimes it is not even your own fault (language implementation…","fields":{"slug":"/engineering/3-simple-ways-to-secure-your-websites-applications/"},"html":"It is hard to write 100% holes-free code, no matter how hard you try. Sometimes it is not even your own fault (language implementation, server setups, etc.) and those factors are likely out of your control. That being said, as developers, we should strive to write our code as safe and secure as possible. Here are my suggestions to keep yourself from being woken up in the middle of the night:
\n1. DO NOT trust any user-input, PERIOD. Not even if it is yours truly. This is the most common attack vector for your web applications, whether it is just a contact form or an API end-point. For example, if a form is implemented to store data in a database, someone can try brute-forcing with classic SQL-injection techniques. Others can certainly try calling your API and see if there are any spotty error-handling issues. Sanitize all inputs as much as you can, and handle all errors behind the scenes properly and gracefully without exposing the actual details to the public.
\n2. UPDATE, UPGRADE and REPEAT. Chances are, a lot of your code is dependent on third-party libraries (open or closed source, does not matter). It is your job to make sure you are using the latest version for them all. When hackers find out you are using outdated or vulnerable code, you are done. I have seen this happening way too many times than I can count over the years when websites got hacked and outdated plugins or libraries was the main culprit.
\nYou might be saying, \"Hey, upgrading that library will break my code!!\". Well, what is your job again? Deal with it.
\n3. Web Application Firewall (WAF) Consider getting one if your server admin lets you, it can potentially save yourself a lot of embarrassments. Just keep in mind though it should not be your only security strategy, as WAFs will not stop all kinds of attacks. It is still your sole responsibility to write good code and repeat step 1 and 2.
\nHappyyyyy coding!
\n","frontmatter":{"date":"June 24, 2019","updated_date":null,"description":null,"title":"3 Simple Ways to Secure Your Websites/Applications","tags":["Engineering"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/a83283c1ebd13e5b72cee8093889ff72/2a4de/hacker.png","srcSet":"/static/a83283c1ebd13e5b72cee8093889ff72/69585/hacker.png 200w,\n/static/a83283c1ebd13e5b72cee8093889ff72/497c6/hacker.png 400w,\n/static/a83283c1ebd13e5b72cee8093889ff72/2a4de/hacker.png 600w","sizes":"(max-width: 600px) 100vw, 600px"}}},"author":{"id":"Karl Wittig","github":null,"avatar":null}}}},{"node":{"excerpt":"Do you remember the Amazon outage that affected several high-profile customers back in 2011? On April 21st, widely-used sites such as Reddit…","fields":{"slug":"/engineering/failover-systems-and-loginradius-99-99-uptime/"},"html":"Do you remember the Amazon outage that affected several high-profile customers back in 2011? On April 21st, widely-used sites such as Reddit and Quora were brought down, and many others experienced latency or were knocked offline, too. Early that morning, as part of normal scaling activities, Amazon staff performed a network change. However, the change was done incorrectly and, after the staff attempted to correct it through a rollback, the inner mechanisms of the service made it unavailable to serve read and write requests. The ‘inner mechanisms’ responsible for the service unavailability are out of the scope of this article, but they are described in the service disruption summary that Amazon published. What interests us here is the strategies that companies can use to mitigate the negative effects on their products when a service they rely on fails. These strategies make up what is known as a failover system.
\nA failover system is a set of mechanisms that perform failover. In computer networking, failover is the process of switching to a redundant or standby server or network upon the abnormal termination of a previously-active server or network. The benefit of a failover system is obvious: with one in place, you can ensure your product or service will be available even when adverse events take place. Uptime—time during which a service is operational—is crucial to the success of your business. If your services are unavailable, you are likely to lose customers and any revenue they would have generated. In an article entitled ‘Lessons Netflix Learned from the AWS Outage,’ Netflix talks about the manual process they used to deal with the Amazon outage and acknowledges the importance of automating this process in the future so they can keep scaling their service. That is, the company acknowledges the importance of having an automated failover system in place instead of relying on a team of top engineers manually making changes every time there is an issue.
\nHow is an automated failover system set up? Let us consider the simplest scenario: setting a failover system for one server. By definition of a failover system, in addition to the main server, we need to have another redundant standby server that we can switch to whenever the main one fails. Since the redundant server must provide the same functionality as the first, it must be identical to it. Additionally, we need a tool that ensures client requests are routed to the redundant server in case of failure of the main one. We can achieve this by using a DNS failover tool. DNS is the internet protocol used to translate human-readable hostnames into IP addresses, and a DNS failover tool makes sure the “dictionary” (DNS tables) used for this translation are updated in the event of an outage. DNS failover tools know when to update the tables by periodically checking on the main server’s status. With these three tools—and some configuration—you can set up a simple, automated failover system. Of course, there are other considerations you must take when setting the failover system, such as ensuring the redundant standby server is hosted in a geographic area different from the main server’s location and using different companies to host your services. That way, your services will be less likely to go down simultaneously.
\nAt LoginRadius, we have set up automated failover systems in all layers of our architecture, which is why we can ensure 99.99% uptime on a monthly basis. With our services, you can be assured your customers will always be able to engage with your business, ensuring you will never lose these customers and any revenue they will generate.
\n","frontmatter":{"date":"June 24, 2019","updated_date":null,"description":null,"title":"Failover Systems and LoginRadius' 99.99% Uptime","tags":["Engineering","AWS"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.0050251256281406,"src":"/static/b25cc95f0b8e5c745ef8652dfb386e3b/40823/tech.jpg","srcSet":"/static/b25cc95f0b8e5c745ef8652dfb386e3b/f836f/tech.jpg 200w,\n/static/b25cc95f0b8e5c745ef8652dfb386e3b/2244e/tech.jpg 400w,\n/static/b25cc95f0b8e5c745ef8652dfb386e3b/40823/tech.jpg 719w","sizes":"(max-width: 719px) 100vw, 719px"}}},"author":{"id":"Ruben Gonzalez","github":"rubenprograms","avatar":null}}}},{"node":{"excerpt":"Bots are tools that are created to automate tedious processes and reduce work. For example, chatbots automate replies to users for customer…","fields":{"slug":"/engineering/a-bot-protection-overview/"},"html":"Bots are tools that are created to automate tedious processes and reduce work. For example, chatbots automate replies to users for customer support, and search bots are used to populate search results on a Google search. However, there are many bots that are crafted for the malicious self-interest of a party. Examples of these hostile bots include DDOS (Direct Denial of Service) botnets and spam bots. This post will provide some information on how to implement bot protection to protect your systems from these nasty bot attacks.
\nOne of the most popular methods of bot protection that is used today is CAPTCHA, which is provided through companies such as ReCAPTCHA, NuCaptcha and Solve Media. CAPTCHA, which stands for “Completely Automated Public Turing Test to tell Computers and Humans Apart”, is an anti-bot measure which consists of a challenge which a user must complete to verify if the user is human. Examples of challenges include translating images of distorted text, or recognition of objects in an image which match a given word. CAPTCHAs are useful in blocking automated form submissions by bots and are constantly being updated to be more friendly to human users. Some of the latest CAPTCHA implementations only require the user to click on a checkbox to pass their validation check.
\nAn example of a ReCAPTCHA with distorted text
\n
To implement CAPTCHA using Google’s ReCAPTCHA solution, you can access Google reCAPTCHA bot protection and login with your Google account. Following that you will be redirected to an interface where you can register your site. Different types of CAPTCHAs can be set up for different events on your domain and can be built to match your use case.
\nAn example of a ReCAPTCHA with a checkbox validation
\n![](\"https://media.giphy.com/media/10p3VEnw29dD44/giphy.gif?ver=1552286291?ver=1552286291\")
CAPTCHAs have a variety of uses, and can be used to prevent automated form completions and even prevent access to your domain. Setting up a CAPTCHA detection solution for different scenarios will typically provide a strong bot defense for your system.
\nSpam honeypots are traps that ensnare bots by placing hidden input fields within a form that reject registration upon being filled in. Bots that use detect form fields through HTML may be programmed to fill in all the input fields in a form including the honeypot. Meanwhile, since the fields are hidden, human users should not be able to see the honeypot and should not be filling in the field.
\nThe implementation of a honey pot can be as simple as implementing an extra form field onto your page that should not be filled in. Hide the element using CSS and set up logic to prevent users that fill in the field from successfully completing the form. A simple implementation can be done with this code:
\n<input id="first-name-input" type="text" name="firstname" value="Fill me in"> <input style="display: none;" id="honeypot-input" type="text" name="honeypot"> <button type="button" onclick="submitForm()" value="button">Submit</button> <button type="button" onclick="fill()" value="button">Fill Honeypot</button> <script> let submitForm = function() { let honeypot = document.getElementById("honeypot-input").value; if(!honeypot) { \n // Handle input submit \n console.log(“Pass”); } \n else { \n // Handle honeypot error \n console.log(“Fail”); } } \n let fill = function() { document.getElementById("honeypot-input").value = "Example"; } \n</script>With the implementation of the above code, if a bot is setup to fill in all input fields on your web page, then the hidden honeypot input will be filled in and the bot will be detected. On the other hand, if a normal user attempts to complete the form on the page, the honeypot would be invisible and the registration will be successful.
\nHoneypots are a solution to weed out basic bots, but they can be easily circumvented depending on how the honeypot is implemented. Regardless, adding a honeypot still provides an additional layer of defense against bot inputs and will help deter some bot traffic on your site.
\nOften times, when bots are created to automate a task, they would be programmed to complete these tasks as quickly as possible to maximize efficiency. As a countermeasure, time lockouts can be set up to prevent bots from repeatedly spamming requests. By setting up a time lockout between requests to your domain, bots which attempt to quickly submit data on your domain will be detected. Meanwhile, human users that are registering onto the site will be working at a slower pace and will not notice the time lockout at all.
\nSetting a timer on form completion does not prevent any bots from affecting your domain, but can significantly slow down their efficiency. Combined with ReCAPTCHA or other anti-bot measures, it can be very useful in reducing the impact of bots.
\nIf an entity accessing your website is from an unexpected location, for example, a Russian IP accessing your domain for an American service, using IP blacklists may be useful to prevent possible bot attacks. IP blacklisting can usually be set up through your hosting services and allows you to customize where users may access your domain.
\nThere are some issues with blacklisting, though. Choosing which targets to blacklist could be a tedious task. Even with a bot set up to detect users with suspicious activity and block them, there could be a chance of a false positive, which may result in users of your domain being blacklisted.
\nIf you want to save your site from spams and denial-of-service attacks you can incorporate a layer of Proof Of Work algorithm in your site. Whenever any client will try to connect to your server they need to commit some of their resources to the Proof Of Work algorithm first and then the server should be connected.
\nWith this approach, any legitimate user would experience just a negligible computational cost, but a spammer/attacker trying to establish a large number of connections would bear the computational cost and time delay, it deters the abuser to do so. There are many POW algorithms which you can use eg:- Client Puzzle Protocol, Productive Puzzle Protocol, Guided Tour Puzzle Protocol
\nOther malicious bots that can impact user experience negatively include, but are not limited to, bots designed for DDOS attacks, spam bots that harvest user data, bots that create links to phishing websites which generate viruses, and malicious bot worms that infect computers.
\nCountermeasures for these bots vary depending on what is being prevented. Honeypot data fields can act as a detection method against bots harvesting data, and with proper preventative training, phishing and scam bots can be handled. Third party services may also be used to protect from different forms of bots. For example, to mitigate impacts of DDOS attacks, a user may implement a solution offered by CloudFlare. Another example is the use of an ad blocker to prevent malware from being drive-by downloaded by intrusive ads.
\nUnless your domain is a highly popular website, or is being targeted by technical security violation experts, there is a good chance that utilizing a simple Google ReCaptcha prompt for form completion is enough to handle any malicious bots that attempt to access your website. For domains with significantly more traffic, paid solutions like Cloudflare might also be useful in dealing with malicious bots.
\nKeep in mind that although some bots are created for bad purposes, a large number of bots exist to automate beneficial tasks and make it easier for humans. Even though there are a significant amount of bots that are not helpful, it is important to embrace how useful benevolent bots actually are.
\n","frontmatter":{"date":"May 31, 2019","updated_date":null,"description":null,"title":"A Bot Protection Overview","tags":["Engineering","Captcha","Spam","Secure","IP"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.2578616352201257,"src":"/static/010dd09dba7a6b0a11d58d980e3f0306/14b42/Productshot.jpg","srcSet":"/static/010dd09dba7a6b0a11d58d980e3f0306/f836f/Productshot.jpg 200w,\n/static/010dd09dba7a6b0a11d58d980e3f0306/2244e/Productshot.jpg 400w,\n/static/010dd09dba7a6b0a11d58d980e3f0306/14b42/Productshot.jpg 800w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Chris Yee","github":null,"avatar":null}}}},{"node":{"excerpt":"OAuth2 is an authorization delegation protocol that allows one party’s accessing of an end user’s resources stored with another party…","fields":{"slug":"/engineering/what-is-the-difference-between-oauth1-and-oauth2/"},"html":"OAuth2 is an authorization delegation protocol that allows one party’s accessing of an end user’s resources stored with another party without sharing any credentials. OAuth2 is often compared with SAML and OpenID Connect as their purposes and uses overlap, however these comparisons often refer to OAuth2 as OAuth. This has resulted in some confusion regarding OAuth2 and OAuth1.
\nOAuth1 was published in 2010, and OAuth2 is a complete rewrite of OAuth1 released in 2012. The following section will go over the most significant needs that led to this rewrite, along with the change associated to address them.
\nOne of the commonly agreed-upon disadvantages of OAuth1 was the lack of support it offers to non-browser based application clients. OAuth2 has different authorization work flows to address authorization initiated by native application clients. This was one of the main advantages OAuth2 has over OAuth1. However, abuse of the flows in favour of convenience and ease can lead to insecure implementations of OAuth2. When using OAuth2 for mobile, desktop, or single page applications, it is recommended to refer to the IETF paper going over best OAuth2 practices for mobile apps: IETF.
\nOAuth1 was often criticized for the barrier it poses to writing a client as each exchange between client, server, and resource server requires a validation of a shared secret. This secret is used to sign the arguments for the authorization request by the client, subsequently the server signs the arguments with the client’s key to verify the legitimacy of the client. The arguments need to be passed in the exact order and is often finicky to write. Moreover, dealing with cryptographic signing of the requests in addition to this can be a pain.
\nOAuth2 has delegated this part of the security to transfer over HTTPS. This means while OAuth1 is protocol-independent, OAuth2 requests must be sent over SSL. Since TLS already provides transport-level message privacy and integrity, some question the merit of arguably redundant client-side signing and argument sorting. Others have brought up concerns with completely delegating security to HTTPS, and mention reasons such as yet-undiscovered zero-day TLS vulnerabilities potentially compromising entire systems.
\nThe conceptualization of OAuth2 defines a resource server in addition to an authorization server. This means there is a clear separation of roles between the server that handles the authorization request, and the server that makes access-control decisions based on the response to the authorization request. This separation of concerns allows support for more flexible use cases.
\nAll of the above points seem to suggest OAuth2 as a superior alternative to OAuth1, and that OAuth1 is obsolete. This is not the case. It is very rare to see a greenfield authorization system using OAuth1, and the only major player still using OAuth1 is Twitter -- they call their version OAuth1.0a. However, as far as security and usability is concerned, OAuth1 is still viable and perhaps even more secure than OAuth2 since it offers additional security on top of TLS-based precautions, and creates barriers in potentially compromising flows. An existing system that uses OAuth1 probably does not need to upgrade to OAuth2. New systems that rely on server-to-server authorization could probably leverage OAuth1 for the additional security as well. On the other hand, use cases that could benefit from a separation of concerns, non-browser support, and ease of client development should go for OAuth2.
\nOAuth2 has received its own share of criticisms. For example, in 2012 Eran Hammer, one of the original authors of OAuth2, withdrew his name from the specification and wrote an article calling out its many flaws. However, even in this article he agreed with the usefulness of OAuth2, and that “at the hand of a developer with deep understanding of web security will likely result in a secure implementation”.
\nOAuth2 is not necessarily more secure than OAuth1, and using OAuth2 does not inherently lead to better security. Many considerations must go into each specific implementation. For starters, the appropriate grant flow must be chosen with care pertaining to the use case; the redirect_uri must be validated sufficiently; and measures must be taken to prevent access tokens from ending up in the browser history. For additional security considerations, see this IETF work in progress draft on OAuth Security Best Current Practice.
\n","frontmatter":{"date":"May 31, 2019","updated_date":null,"description":"Learn about the differences between OAuth 1.0 and OAuth 2.0 and how OAuth 2.0 is superior to OAuth 1.0","title":"OAuth 1.0 VS OAuth 2.0","tags":["Oauth","Engineering"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/1c2dae61b8f7fee8ab8408c5d18cd8b4/14b42/pexels-photo-373543.jpg","srcSet":"/static/1c2dae61b8f7fee8ab8408c5d18cd8b4/f836f/pexels-photo-373543.jpg 200w,\n/static/1c2dae61b8f7fee8ab8408c5d18cd8b4/2244e/pexels-photo-373543.jpg 400w,\n/static/1c2dae61b8f7fee8ab8408c5d18cd8b4/14b42/pexels-photo-373543.jpg 800w,\n/static/1c2dae61b8f7fee8ab8408c5d18cd8b4/47498/pexels-photo-373543.jpg 1200w,\n/static/1c2dae61b8f7fee8ab8408c5d18cd8b4/0e329/pexels-photo-373543.jpg 1600w,\n/static/1c2dae61b8f7fee8ab8408c5d18cd8b4/2d44f/pexels-photo-373543.jpg 2250w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ti Zhang","github":null,"avatar":null}}}},{"node":{"excerpt":"This blog post goes over how you can connect your SAAS/web application with the Azure AD world. Let’s take a look at how Azure AD works as…","fields":{"slug":"/engineering/azure-ad-as-an-identity-provider/"},"html":"This blog post goes over how you can connect your SAAS/web application with the Azure AD world. Let’s take a look at how Azure AD works as an identity provider to provide your users with the ability to log in. e.g if anyone using Office 365, able to log on with their standard account or a federated one.
\nWindows Azure provides a number of identity-based technologies to support such kind of requirements. As a means of illustrating this, we’ll show an example using Azure AD as an Identity Provider (IdP), connecting up to the LoginRadius SAAS application using the LoginRadius Admin Console.
\nHere are the meanings of the terms, we have used above:
\nSign-On Url: This is where you want to send users to when accessing the \"application\".
\nReply URL: It's the Reply URL which is the address to which Azure AD will send the SAML authentication response.
\nOn the Service Provider side, the metadata from the tenant, Azure Identity Provider needs to be parsed and added to the configuration file. This is done by downloading the Azure IdP metadata file directly, e.g.
\nhttps://login.microsoftonline.com/<AzureTenantID>/federationmetadata/2007-06/federationmetadata.xml
This is all you need to know to go about creating a new application on the Azure portal and use Azure Ad as an Identity provider for login. With these and a number of services, Azure offers a solid convergence point for brokering connections with your web applications and workspaces.
\n","frontmatter":{"date":"May 30, 2019","updated_date":null,"description":null,"title":"Azure AD as an Identity provider","tags":["Engineering","Authentication","AzureAD"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/c3f65c00249c3107c5efe318d12ef2f9/bc59e/TN0lxUr0.png","srcSet":"/static/c3f65c00249c3107c5efe318d12ef2f9/69585/TN0lxUr0.png 200w,\n/static/c3f65c00249c3107c5efe318d12ef2f9/497c6/TN0lxUr0.png 400w,\n/static/c3f65c00249c3107c5efe318d12ef2f9/bc59e/TN0lxUr0.png 512w","sizes":"(max-width: 512px) 100vw, 512px"}}},"author":{"id":"Team LoginRadius","github":"LoginRadius","avatar":null}}}}]},"markdownRemark":{"excerpt":"Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie…","fields":{"slug":"/engineering/identity-impact-of-google-chrome-thirdparty-cookie-restrictions/"},"html":"Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients.
\nWhat does it mean for user authentication?
\nOn one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes).
\nOn the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies.
\nIn this article, we’ll discuss:
\nThird-party cookie restrictions affect user authentication in three ways, as follows.
\nIf your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app.
\nIf you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials.
\nIf you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future.
\nFor example, you have apps at example.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.
Federated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO.
\nUsually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits.
\nFor example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords.
\n\n\nNote: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method).
\n
Google has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative.
\nSpecific to authentication, Google recommends the following:
\nCHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds.
\nFor example, a user visits a.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com.
If the user visits b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.
You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes.
\nIf you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions.
\nHowever, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues.
\nWith Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage.
\nStorage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context.
\nIt is most suitable when loading cross-site resources and interactions, such as:
\nVerifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible.
\nAs it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options.
\nWith Related Website Sets, you can declare a primary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.
Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets
\nIt provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe.
\nIt is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature.
\nThe top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using resuestStorageAccessFor() API.
If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication.
\nRelated Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited.
\nFedCM API enables federated SSO without third-party cookies.
\nWith FedCM API, a user follows these steps for authentication:
\nYou can access a user demo of FedCM here: FedCM.
\nFor more information about implementing federated SSO with FedCM API, go through the FedCM developer guide.
\nFirstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different.
\nWe’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers.
\nPlease subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out.
\nThe proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community.
\nMoreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does.
\nFrom LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out.
\nTop-level site: It is the primary site a user has visited.
\nFirst-party cookie: A cookie set by the top-level site.
\nThird-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited a.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.