![\"fun\"](\"https://media2.giphy.com/media/3oEjHKiDeYrKnjwGFq/giphy.gif\")
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.
Hacktoberfest 2021 is the 8th edition of Hacktoberfest hosted by DigitalOcean. It is an open source festival celebrated during October every year, encouraging people worldwide to actively participate and contribute to participating open source projects hosted across GitHub and GitLab.
\nIn fact, Hacktoberfest 2020 had attracted 169,886 participants and 116,361 participating open source repositories, representing 135 countries.
\nYou can simply register yourself here and start contributing to any participating open source project from Oct 01 - Oct 31. And if you meet the contribution criteria set by DigitalOcean, you’ll receive a Hacktoberfest t-shirt from DigitalOcean!
\nAdditionally, if you make successful contributions to LoginRadius open source projects, you’ll separately receive a LoginRadius branded Hacktoberfest t-shirt from us, recognizing and thanking you for your valuable contributions.
\nLoginRadius is an industry-leading Customer Identity and Access Management (CIAM) provider with a mission to secure every identity on this planet.
\nAt LoginRadius, we’re committed to making our cloud platform more accessible for developers across tech stacks, so they can quickly implement user registration and authentication processes in their applications and become more efficient at focusing on core business features.
\nWe’ve always loved open source and the many great things it has done for the software development community and businesses. This inspired us to open source many of our projects, including SDKs, LR CLI, and Async Blog, a leading publication for developers by developers.
\nThrough our open source projects, we actively collaborate with the developer community and drive change and innovation for the optimistic progress of everyone.
\nWhen you contribute to our open source projects, you’re helping the whole developer community become efficient, productive, and helping them manage user identities and authentication on their applications securely and scalably.
\nThe exciting part about being involved in the open source community is that no matter how small or big your contributions are, the community will welcome your efforts and collaborate with you positively, sharing feedback and expressing gratitude.
\nEspecially with LoginRadius open source projects, your contributions can make a big difference! We also try making your collaboration with us more enjoyable.
\nPlease note that only contributions that add significant value to our projects will be eligible for swag. This will be at our sole discretion. But you may go ahead and contribute in any way you would like.
\nYou should have a basic to intermediate understanding of the following:
\nEach of the following public repositories on GitHub will have a list of issues listed. You can choose to work on these issues based on your skills and expertise in solving them.
\nAt LoginRadius, we value your contributions and proactively collaborate with you to get your contribution accepted.
\nBut one thing to keep in mind is that we don’t tolerate spamming.
\nSo, what is spamming?
\nSpamming is creating a pull request for the sake of it and not adding value in any way. We’ll identify spam pull requests and report them according to GitHub guidelines.
\nAnyways, you don’t have to worry about spamming accidentally: it seldom occurs without a clear intention. If we identify something as spam, we’ll let you know and help you understand why it is marked as spam.
\nYou can also easily find issues with the hacktoberfest label in order to know which repositories are seeking contributions. Or, you can simply click here to find all the issues needing contribution.
\nThat all being out of the way, here are the open source projects for which we’re seeking your valuable contributions:
\nLoginRadius CLI: We understand that developers love the simplicity and efficiency offered by CLI. So, we recently launched CLI for LoginRadius, which helps implement and manage LoginRadius CIAM faster than ever.
\nAs our CLI still has room for becoming great, we seek your contributions in any way possible to make it better and help developers become more productive.
\nAsync Blog: This is our open source blog created for developers by developers. If you’ve expertise in solving issues and fixing errors, please come forward and share your expertise with the world.
\nWe have a few issues created for this repository based on our research about what problems developers are currently facing and trying to solve them. Share your expertise, write a blog, and be a holding hand for developers in need!
\nPlease note that each project will have specific guidelines on how to contribute in general and raise pull requests. Also, each project will have issues listed that you can pick and work on.
\nIf you’re facing any issues with locally running a project or something else, please feel free to raise an issue for the project. Our team will help you out.
\nBy actively participating in Hacktoberfest, you make the open source community more sustainable, and, in turn, this makes you feel at home. Empowering one another is what best depicts the open source philosophy and is a reward in itself.
\nHowever, we want to make it more fun by sending cool t-shirts to all the accepted/eligible contributors. Just make sure to fill this form after you raise a pull request.
\nDon’t forget that your contributions to our projects also count towards your overall Hacktoberfest contributions calculated by DigitalOcean — and if you’re eligible, they’ll send you another t-shirt as well.
\nLet’s have fun with Hacktoberfest 2021!
\n
It is scientifically proven that helping others makes people happy. Probably no one knows this better than the developer community around the world, which continues to amaze by contributing extensively to free and open source software.
\nAnd there is freeCodeCamp community, a nonprofit started in 2014 by Quincy Larson. It has been helping thousands of aspiring developers learn web development and find their first software jobs. The community features a self-paced learning platform that helps learn various web technologies, including Bootstrap, D3, jQuery, and React, among many others.
\nBeing a nonprofit, freeCodeCamp entirely works based on charitable donations and contributions of developers to maintain its learning platform. In fact, it is so efficient that with every $5 in donation, it can provide more than 250 hours of learning. And it is so effective that some of its alumni work for marquee tech companies like Apple, Google, Microsoft, and Amazon, among others.
\nIn 2013, just a year before freeCodeCamp was established, we founded LoginRadius with a vision to secure every identity on this planet. From our early beginnings, we have developed LoginRadius CIAM to empower developers to build more secure applications and simplify the implementation of customer identity and access management on their production applications to save development and maintenance time. Today, burgeoning startups to Fortune 500 companies trust LoginRadius, and we're now collectively handling 1.17 billion user identities for our customers worldwide.
\nWe are as obsessed as freeCodeCamp to support and enable the developer community to do much more and make this world a better place. And we wanted to continuously help the freeCodeCamp community in any way possible.
\nToday, we are a proud sponsor of freeCodeCamp and supporting the community's developers.
\nSignup here if you're a developer from the freeCodeCamp community. And we'll offer $200 credits so you can leverage LoginRadius CIAM — beyond the free developer tier — to implement highly secure, user-centric customer identity and access management.
\nThis is indeed a moment of joy and pride for everyone at LoginRadius. We would like to extend our gratitude to freeCodeCamp for letting us be a part of its journey in strengthening the developer community.
\nBy the way, if you want to share your expertise with the developer community, please feel free to write for the LoginRadius Blog portal. We have an open for contributions policy so anyone around the world can contribute. Find more details on our public GitHub repo.
\n![\"Squad](\"https://media.giphy.com/media/xUPGcGJJMFeAPhqrfi/giphy.gif\")
While most of you — developers and architects — understand the need for strong password security and practice it, your users might not.
\nFor years security researchers have been hollering about the risks of weak, repeated passwords. Still, average Joe seems to be complacent about it and reuses the same or similar passwords across multiple logins, despite the fact that even a strong password is secure only if used for a single login.
\n![\"https://twitter.com/JohnLegere/status/371699808014462976/photo/1\"](\"/a2a2f64aa269670aeabac698039c9387/incorrect.webp\")
A good password manager can alleviate the problem of remembering tens of passwords, if not hundreds. However, in reality, the average Joe doesn't invest in a password manager and carries on with life.
\nSo, what's the greater risk? You may ask.
\nMillions of data records, including login credentials, are being exposed in data breaches, which continue to make headlines around the world. In fact, data breaches globally exposed more than 36 billion records in 2020.
\nCybercriminals get access to these exposed records in black markets (generally on the dark web) and use them to perform credential stuffing and account takeover attacks or commit fraud.
\nWhether it's yours or your users' fault, such type of attacks damage brand reputation, make your business liable to legal damages, and impact user experience.
\nYou should take the onus upon yourself to ensure user access to your apps or portals is as secure as possible without impacting user experience. This is where risk-based authentication (RBA) — also known as adaptive authentication — comes into play.
\nRBA is a process of assessing the risk of an authentication request in real-time and requesting additional layers of authentication and identification based on the risk profile to validate that a user attempting to authenticate is who they claim to be.
\nThe risk is usually assessed based on various parameters and the environment from which the user is attempting to authenticate. Some common parameters used for risk profiling include:
\nBased on the risk assessed, an RBA system requests additional methods of authentication, such as:
\nRBA is different from multi-factor authentication (MFA). MFA is a static authentication method — that is, regardless of the risk of an authentication request, this method requires an additional layer(s) of validation.
\nOn the other hand, RBA is a non-static authentication method that requires additional authentication factors only when necessary based on the risk profile — as a result, RBA provides a better user experience.
\nNow, it's clear that better safe than sorry when it comes to authenticating users, and implementing RBA reduce account compromise risk on your apps.
\nThat said, RBA doesn't have to stop at user authentication; you can extend it to signups, payments, and other types of online transactions.
\nYou have two options:
\nYes, developing an RBA system in-house is possible. But, you should ponder upon some important details:
\nIf you got convincing responses to the above questions, you may go ahead and develop your in-house RBA system.
\nBut a lot of you might not have that sort of resources or just don't want to focus on non-core development projects. In this case, you can rely on a reputed RBA provider -- for example, LoginRadius.😉
\nWhen choosing an RBA provider, make sure the solution meets the following criteria:
\nOnce you have evaluated and finalized the vendor, it is vital to test the RBA solution and ensure that the user experience is as expected while minimizing risk.
\nWant to learn more about RBA and test how RBA works in LoginRadius? Signup for a free account here.
\n","frontmatter":{"title":"What is Risk-Based Authentication? And Why Should You Implement It?","author":{"id":"Raghunath Reddy","github":"raghunath-r-a","avatar":null},"date":"May 25, 2021","updated_date":null,"tags":["RBA","Authentication"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/5b01c860ee1c60243f1ede7dc2a060c2/58556/cover.webp","srcSet":"/static/5b01c860ee1c60243f1ede7dc2a060c2/61e93/cover.webp 200w,\n/static/5b01c860ee1c60243f1ede7dc2a060c2/1f5c5/cover.webp 400w,\n/static/5b01c860ee1c60243f1ede7dc2a060c2/58556/cover.webp 800w,\n/static/5b01c860ee1c60243f1ede7dc2a060c2/99238/cover.webp 1200w,\n/static/5b01c860ee1c60243f1ede7dc2a060c2/7c22d/cover.webp 1600w,\n/static/5b01c860ee1c60243f1ede7dc2a060c2/15103/cover.webp 3999w","sizes":"(max-width: 800px) 100vw, 800px"}}}},"fields":{"authorId":"Raghunath Reddy","slug":"/engineering/risk-based-authentication/"}}}]},"authorYaml":{"id":"Raghunath Reddy","bio":"Raghunath is a technical content writer with a graduate degree in computer science. He is also a Conversion Rate Optimization (CRO) enthusiast and enjoys studying the English language.","github":"raghunath-r-a","stackoverflow":null,"linkedin":"raghunathreddyalla","medium":null,"twitter":"_raghunath","avatar":null}},"pageContext":{"id":"Raghunath Reddy","__params":{"id":"raghunath-reddy"}}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}