When JSON Web Tokens are created, they are typically signed by its issuer. This allows the recipient of the token to validate that the token received contains all of the information encoded by the issuer unmodified and as intended.
\nA signature is not to be mistaken for encryption! The fact that a JSON token is signed does not mean that the data enclosed is unreadable by third parties. All a signature does is ensure that the message is authentic, which it achieves by allowing the recipient to compare the data they’ve received with a trusted claim included in the data (the signature).
\nJWTs are most commonly signed using one of two algorithms: HS256 (HMAC using SHA256), and RS256 (RSA using SHA256).
\nA signature can only be created by someone possessing a secret key, and the original payload. Signatures are generally formed by combining the data to be signed with a secret key, either by appending them together and hashing them (HS256), or by encrypting a representation of that data (a hash) using the secret key (RS256).
\nIn both signing algorithms, the data is formatted into an immutable representation in a way that a recipient can check that the creator of the signature was in possession of that particular secret key.
\nHS256 is a symmetric signing method. This means that the same secret key is used to both create and verify the signature.
\nThe issuer appends the JWT header and payload with the secret key, and hashes the result using SHA256, creating a signature. The recipient uses their copies of the secret key, JWT header and payload in the same way to reproduce the signature, checking to see if they match.
\nAside from some incredibly unlikely scenarios, the only way for these signatures to be consistent is if the JWT header, payload and secret shared between the two parties are identical.
\nRS256 is an asymmetric encryption method. This differs from a symmetric scheme in that rather than using a single secret key, a pair of seperate keys are used to encrypt and decrypt the data.
\nThe issuer generates a hash of the JWT header and payload using SHA256, and encrypts it using the RSA encryption algorithm, and their private key. The recipient uses their public key to decrypt the signature ciphertext, and then compares it to a hash they’ve reproduced using their copy of the JWT header and payload, checking for consistency.
\nThe only way that these resulting hashes are consistent is if the JWT header and payload shared between the two parties are identical, and the public key corresponds to the private key used to encrypt the hash.
\nBoth signing schemes are effectively secure, with HS256 being a little faster. However, given this use case, the difference in speed is not particularly relevant.
\nThe main consideration on which to use, is in my opinion the symmetric vs asymmetric property of each:
\nHaving an unsecured publicly available key is useful in many cases. For example, it can be published openly on the internet as part of a metadata endpoint, allowing JWT configurators to automatically retrieve the key, making for a straightforward and automatic JWT setup. As such, RS256 may be more suitable for situations where data is exchanged between two independent parties.
\nHaving a shared secret key can however also be useful in some cases. For example, if the issuer and recipient were both managed by a single party, the two applications would be able to share configurations without having to manage two separate keys. As such, HS256 may be more suitable for situations where data is exchanged within a single party
\n","frontmatter":{"date":"September 24, 2020","updated_date":null,"description":"Deciding between which signing algorithm to use.","title":"JWT Signing Algorithms","tags":["JWT","JSON Web Tokens"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/9bdbc02fd668c5c3166222b458455efb/ee604/unsplash.png","srcSet":"/static/9bdbc02fd668c5c3166222b458455efb/69585/unsplash.png 200w,\n/static/9bdbc02fd668c5c3166222b458455efb/497c6/unsplash.png 400w,\n/static/9bdbc02fd668c5c3166222b458455efb/ee604/unsplash.png 800w,\n/static/9bdbc02fd668c5c3166222b458455efb/f3583/unsplash.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Nick Chim","github":"nickc95","avatar":null}}}},{"node":{"excerpt":"Rendering is an essential procedure a programmer has to manage in frontend development. In React, the render() method is the only required…","fields":{"slug":"/engineering/understanding-react-rendering/"},"html":"Rendering is an essential procedure a programmer has to manage in frontend development. In React, the render() method is the only required method in a class component and is responsible for describing the view to be rendered to the browser window. Coupled with the clever way React operates around its virtual DOM concept, there are certain subtleties in how this method works. Understanding them will greatly benefit any aspiring React developer.
\nThroughout this writing, I will reference this codepen for a demonstration of discussed behaviors.
\nrender() 101First of all, render() is not user callable. It is part of the React component lifecycle. Generally, it gets called by React at various app stages when the React component instantiates for the first time, or when there is a new update to the component state. Render does not take any arguments and returns a JSX.Element which contains the view hierarchy of the current component. This view hierarchy will later be translated into HTML and displayed in the browser window.
As mentioned before, render() is not user callable as it is an event that happens in the component’s lifecycle. With that said, if it is absolutely necessary to render the view manually, you can instead call the built-in class method forceUpdate(). Keep in mind that this is considered an anti-pattern. If you were designing sensible React components, its state and props changes should naturally control the render process, and you should never feel the need to make a manual call.
Within the lifecycle, these are the scenarios where render is called:
\nconstructor() call.setState() callIf you have the Codepen opened at this point, before anything is rendered you will see 2 alert messages from the browser: \"render() is called in Parent component!\", and \"render() is called in Child component!\". These messages are invoked from the corresponding render() methods of the example's parent and child component. They serve to introduce the first case of render() invocation: when the component is first instantiated.
Once the set of alerts is dismissed, a very simple UI will render:
\nThe dotted border line distinguishes between elements that belong to the Child component of the example (inside the dotted line) versus the Parent component.
\nchildElementText state of the Parent component, which in turns updates the text prop of the Child component, triggering a render in both Parent and Child. onChildPropChange = () => {\n this.setState({\n childElementText: "I am the child element! I am updated following a prop change."\n })\n }helloWorldMessage state within Child component, triggering a render following a state change. onTextChange = () => {\n this.setState({\n helloWorldMessage: "Hello React! (state change after setState call)"\n })\n }A visual and interactive reference to the React lifecycle can be found here.
\nIt is worth noting that following a props update or setState(), the method shouldComponentUpdate() is invoked to determine whether render() should be called. By default, this method always returns true. But it can be overloaded to implement custom logic. It is the actual way to define custom render behavior in each React component.
The shouldComponentUpdate() provides you with nextProp and nextState as arguments, which allows you to compare the current state and props of the component. For example, this code block will invoke render() only when the text prop changes:
shouldComponentUpdate(nextProps: NewComponentProps, nextState: NewComponentState) {\n if (this.props.text !== nextProps.text) {\n return true;\n } else {\n return false;\n }\n }The characteristics and behaviors mentioned above made it imperative that render() is a pure function. That means inside render(), you should not make an update to the component's states or props (no setState() call nor Redux state update). This makes sense because an update to the component will then trigger a new render() call, which can potentially lock you into an infinite render loop.
In terms of return value: render() returns a single JSX element, as mentioned above. This comes with certain implications:
<div>, or a <React.Fragment>. It is worth noting that once rendered, <React.Fragment> will vanish from the DOM structure. It is only meant to be a wrapper component and does not appear in the final DOM in the browser. This makes it a more sensible choice over a <div> wrapping to avoid nesting div’s.render() method, it is helpful to think about how the entire UI will look like at a moment in time, instead of thinking about how a certain element updates over time. “Thinking about how the UI should look at any given moment, rather than how to change it over time, eliminates a whole class of bugs.”key propThe render() method in each React component then feeds into what is called the Reconciliation Algorithm. This is the primary algorithm that dictates how React renders the real DOM in your browser based on a virtual DOM maintained internally by React. To intelligently determine what needs to be rendered on every call, React compares the current state of the virtual DOM and the real one and only makes changes to the physical DOM where it recognizes that the UI has been updated.
While not every single detail is known about React’s reconciliation algorithm, the characteristics detailed in the official documentation are enough for us to start phasing out certain suboptimal rendering patterns, thus writing a more robust render() method.
For instance, given this DOM subtree:
\n<div>\n <span key="li-1">list item 1</span>\n\n <span key="li-2">list item 2</span>\n\n <span key="li-3">list item 3</span>\n</div>If a <NewComponent> is then added to the top of the list:
<div>\n <!-- previously <span>list item 1</span> - element is detached and <NewComponent /> instantiated -->\n <NewComponent />\n\n <!-- previously <span>list item 2</span> - content will be updated to "list item 1" -->\n <span>list item 1</span>\n\n <!-- previously <span>list item 3</span> - content will be updated to "list item 2" -->\n <span>list item 2</span>\n\n <!-- new <span>list item 3</span> is element created -->\n <span>list item 3</span>\n</div>If instead <NewComponent> is added to the bottom:
<div>\n <!-- previously <span>list item 1</span> - no change -->\n <span>list item 1</span>\n\n <!-- previously <span>list item 2</span> - no change -->\n <span>list item 2</span>\n\n <!-- previously <span>list item 3</span> - no change -->\n <span>list item 3</span>\n\n <!-- new instance of <NewComponent /> is added -->\n <NewComponent />\n</div> In the example above, appending <NewComponent> to the end of the list will result in 1 new instantiation, versus 1 instantiation, 3 updates and 1 tear down. In a larger application scale, this will prove to be a significant performance difference in the long run.
If you have ever tried to use the map() method to iterate over an array to render a list of elements, it is likely that you have seen React complaining about a missing key prop to each rendered list item. So what does the key actually do?
A key is React’s way to recognize elements in the DOM tree, comes reconciliation time. When React is parsing all children of an element, it can leverage keys to match elements that were present from the last update. That allows you to shuffle the order of child elements without interfering with the algorithm. As long as the key matches between updates, React will preserve the element configuration.
Coming back to the example above, let’s add keys to all the existing list items:
\n<div>\n <span key="li-1">list item 1</span>\n\n <span key="li-2">list item 2</span>\n\n <span key="li-3">list item 3</span>\n</div>In this case, if we were to add an extra “list item 4” at the top of the list, it would not come with the same performance penalty:
\n<div>\n <!-- new item - <span> is instantiated -->\n <span key="li-4">list item 4</span>\n\n <!-- matched with the old "li-1" key - element stays unchanged between renders -->\n <span key="li-1">list item 1</span>\n\n <!-- matched with the old "li-2" key - element stays unchanged between renders -->\n <span key="li-2">list item 2</span>\n\n <!-- matched with the old "li-3" key - element stays unchanged between renders -->\n <span key="li-3">list item 3</span>\n</div>In case a subtree is generated using a map() or other iterative methods, React requires that keys are provided with the element. However, even in case a DOM subtree is manually added, keys should be provided on subtrees that have complex behaviors regarding conditional rendering.
React is a clever framework that offers performance through its rendering scheme, so it follows that, as developers, we should leverage it appropriately to help build performant applications. With that said, it is not a miracle device that optimizes out inefficiencies from the developer’s end, but a tool to be utilized. Understanding the render() nd its implication to the reconciliation algorithm is the first step to make sure we are leveraging the framework instead of working against it. It is also one of the first steps to mastering React.
Ajax stands for Asynchronous Javascript and XML. Ajax is a programming technique that allows us to create dynamic, complex, and asynchronous web applications. Ajax allows us to send and receive data from the webserver asynchronously without interfering with the current state or behavior of the web page or application.
\nXHR is the XMLHttpRequest Object which interacts with the server. Ajax technique in the nutshell leverages the XHR request to send and receive data from the webserver. This object is provided by the browser’s javascript environment. It transfers the data between the web browser and server.
\n// Insert One document\nbook1 := Book{"Animal Farm", "George Orwell", "0451526341", "Signet Classics", 100}\ninsertResult, err := booksCollection.InsertOne(context.TODO(), book1)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Println("Inserted a single document: ", insertResult.InsertedID)To insert multiple documents at once we need to create a slice of Book object and pass it to collection.InsertMany
// Insert multiple documents\nbook2 := Book{"Super Freakonomics", "Steven D. Levitt", "0062312871", "HARPER COLLINS USA", 100}\nbook3 := Book{"The Alchemist", "Paulo Coelho", "0062315005", "HarperOne", 100}\nmultipleBooks := []interface{}{book2, book3}\n\ninsertManyResult, err := booksCollection.InsertMany(context.TODO(), multipleBooks)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Println("Inserted multiple documents: ", insertManyResult.InsertedIDs)We can update a single document by function collection.UpdateOne. It requires a filter document to match documents in the collection and an updated document to describe the update operation. You can build these using bson.D types. The below code will match the book with ISBN 0451526341 and increment the copies field by 10
//Update one document\nfilter := bson.D{{"isbn", "0451526341"}}\n\nupdate := bson.D{\n {"$inc", bson.D{\n {"copies", 10},\n }},\n}\n\nupdateResult, err := booksCollection.UpdateOne(context.TODO(), filter, update)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Printf("Matched %v documents and updated %v documents.\\n", updateResult.MatchedCount, updateResult.ModifiedCount)\n\nYou can also update more than one documents at once in a single collection by function
\ncollection.UpdateMany, In it, we need to pass filter document and update document same ascollection.UpdateOne
To find a single document, we can use function collection.FindOne(), we will pass a filter document and decode the result in the Book type variable
// A variable in which result will be decoded\nvar result Book\n\nerr = booksCollection.FindOne(context.TODO(), filter).Decode(&result)\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Printf("Found a single document: %+v\\n", result)To find multiple documents, we use function collection.Find(). This method returns a Cursor, It provides a stream of documents on which we can iterate or we can get all the docs by function cursor.All() in a slice of Book type.
cursor, err := booksCollection.Find(context.TODO(), bson.D{{}})\nif err != nil {\n log.Fatal(err)\n}\nvar books []Book\nif err = cursor.All(context.TODO(), &books); err != nil {\n log.Fatal(err)\n}\nfmt.Printf("Found multiple documents: %+v\\n", books)We can delete documents from a collection using functions collection.DeleteOne() or collection.DeleteMany(). Here you pass bson.D{{}} as the filter argument, which will match all documents in the collection.
deleteCollection, err := booksCollection.DeleteMany(context.TODO(), bson.D{{}})\nif err != nil {\n log.Fatal(err)\n}\nfmt.Printf("Deleted %v documents in the books collection\\n", deleteCollection.DeletedCount)\n\nEntire collection can be dropped using the collection.Drop() function, it will remove all documents and metadata, such as indexes from the collection
\n
Once you have done all the operation, don't forget to close the MongoDB connection
\nerr = client.Disconnect(context.TODO())\n\nif err != nil {\n log.Fatal(err)\n}\n\nfmt.Println("Connection to MongoDB closed.")Now you can easily use MongoDB as Datasource in your go application, You can found the complete code used in this tutorial on our Github Repo
\n","frontmatter":{"date":"September 21, 2020","updated_date":null,"description":"Learn how to use MongoDB as a data source for your Go application using the mongo-go driver","title":"Using MongoDB as Datasource in GoLang","tags":["Go","MongoDB"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/462778a1e1bc2468232a76699885ec69/ee604/gomongo.png","srcSet":"/static/462778a1e1bc2468232a76699885ec69/69585/gomongo.png 200w,\n/static/462778a1e1bc2468232a76699885ec69/497c6/gomongo.png 400w,\n/static/462778a1e1bc2468232a76699885ec69/ee604/gomongo.png 800w,\n/static/462778a1e1bc2468232a76699885ec69/f3583/gomongo.png 1200w,\n/static/462778a1e1bc2468232a76699885ec69/5707d/gomongo.png 1600w,\n/static/462778a1e1bc2468232a76699885ec69/eeb1b/gomongo.png 1920w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Puneet Singh","github":"puneetsingh24","avatar":null}}}},{"node":{"excerpt":"We often hear that JavaScript is a single-threaded programming language, which means it executes all of the instructions line by line in a…","fields":{"slug":"/engineering/understanding-event-loop/"},"html":"We often hear that JavaScript is a single-threaded programming language, which means it executes all of the instructions line by line in a synchronous manner. Thus since everything works on the main thread, there seems to be no possibility of executing parallel processes in JavaScript.
\nBut now let's assume that we have a function which is taking some time to execute, for example in the below function which is having a loop over 10k times, the console.log() would be executed once the loop is over and in the meantime, our UI interaction with the browser would be interrupted.
function someTimeTakingFunc() {\n for(var i = 0; i < 10000; i++) {\n\n }\n console.log("Loop has been executed")\n}The above scenario seems to be impractical, but there might be cases where any function can take an indeterminate amount of time and our main thread would be blocked, for example calling an API for fetching data from the server-side. And this is the practical use case we are dealing with in development every day. So how JavaScript handles this and where does the event loop come into the picture? We will surely get to know this, but before moving further, let's understand the basic memory architecture in JavaScript.
\nThe Javascript Engine consists of two main components:
\nCall stack is a LIFO (last in first out) data structure. All of the function calls are pushed into this call stack and are said to be a frame. In short function, a stack is nothing but the simple stack data structure which keeps track of the function currently being executed.
\nLet's understand the above concept with the example of the following code snippet:
\n function square(b) {\n return b * b ; \n }\n\n function cube(x) {\n return x * square(x)\n }\n\n console.log(cube(8));The above snippet is an example of defining a cube function, which is calling a square function, to find the cube of a number passed in the argument. But how does this work in call stack? Let's understand step by step:
console.log() line, this code/function is pushed into the call stack. console.log() function is called the cube function, hence this function is pushed into the stack. cube function is calling the square function, and now this would be pushed into the stack. square function is executed, and the result is returned, then the square function is popped out of the stack. square function result, so cube function would be executed and popped out of the call stack. console.log() would be executed and this function would be popped out of the stack and the stack would now be empty. \n setTimeout(function(){\n console.log("Executed";)\n }, 2000);Now when a setTimeout operation is processed in the call stack. On its execution, it calls a web API which fires a timer for 2000 milliseconds. After 2000 milliseconds has been elapsed, the web API, place the callback function of setTimeout in the event queue.
Here need to mention that, just placing our function does not necessarily imply that the function will get executed. This function has to be pushed into the call stack for execution and here the event loop comes into the picture. The event loop waits for the function stack to be empty, once the call stack is empty this will push the first function from the event queue to the call stack, and in this way, the desired function will be called.
\nThus event loop works in a cyclic manner, where it continually checks whether or not the call stack is empty. If it is empty, new functions are added from the event queue. If it is not, then the current function call is processed.
\n","frontmatter":{"date":"September 19, 2020","updated_date":null,"description":"Learn the basic concepts about the JavaScript Event Loop.","title":"Understanding event loop in JavaScript","tags":["JavaScript","event-loop","call stack","event queue","multi-threaded"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.7699115044247788,"src":"/static/b6cf96ed7545f05ed0b5cd58325c4847/ee604/index.png","srcSet":"/static/b6cf96ed7545f05ed0b5cd58325c4847/69585/index.png 200w,\n/static/b6cf96ed7545f05ed0b5cd58325c4847/497c6/index.png 400w,\n/static/b6cf96ed7545f05ed0b5cd58325c4847/ee604/index.png 800w,\n/static/b6cf96ed7545f05ed0b5cd58325c4847/f3583/index.png 1200w,\n/static/b6cf96ed7545f05ed0b5cd58325c4847/e4d72/index.png 1280w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Aman Agrawal","github":"aman-agrwl","avatar":null}}}},{"node":{"excerpt":"Have you ever thought about what the world would be like if open-source didn't exist? It's hard to imagine a world without open source these…","fields":{"slug":"/engineering/loginradius-supports-hacktoberfest-2020/"},"html":"It's hard to imagine a world without open source these days. Open source powers the biggest organizations of today's world. Open-source software like Linux runs most of today's servers and also powers the Android Operating System.
\nHacktoberfest is a month-long celebration of open-source software in October month run by DigitalOcean in partnership with GitHub and DEV. Hacktoberfest is open to everyone in our global community!
\nFrom Official Website:
\n\n\nHacktoberfest is open to everyone in our global community. Whether you’re new to development, a student, long-time contributor, event host, or company of any size, you can help drive the growth of open source and make positive contributions to an ever-growing community. All backgrounds and skill levels are encouraged to complete the challenge.
\n
The purpose of this month-long celebration is to get people started in open source and give back to the open-source community.
\nIt is the easiest way to get into open source for people who have never contributed to open-source community or find it difficult to contribute.
\nAnyone can contribute to hacktoberfest by registering at hacktoberfest website anytime between 1st October to 31st October.
\nDuring this time, anyone who wishes to be part of this month-long fest needs to open four quality pull requests on any of the open-source projects on Github.
\nFinding projects can be a bit challenging. It can be the tools you are already using, or different tools can be used to find the issues based on various labels. Tools like issuehub are really helpful for the same.
\nThis year LoginRadius is going to be part of Hacktoberfest by open-sourcing a lot of its projects and accepting contributions on them including its Engineering Blog.
\nLike I said, this year LoginRadius will be part of hacktoberfest and yes, we are here with some cool swags. We have got around 500 t-shirts for people contributing to our open source repositories. We will soon share details on how to get LoginRadius swags as well as our open source repositories on our Blog.
\nStay tuned and don’t forget to mention your open-source projects for us to contribute.
\n","frontmatter":{"date":"September 18, 2020","updated_date":null,"description":"Open Source is changing the world, One Pull Request at a time. Join LoginRadius this year in supporting hacktoerbest 2020 by contributing to open source and get cool swags from LoginRadius","title":"LoginRadius Supports Hacktoberfest 2020","tags":["hacktoberfest","open-source","LoginRadius"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5873015873015872,"src":"/static/ccafb9d75be0248e67ee6c688fd6cee5/ee604/hacktober-fest-banner.png","srcSet":"/static/ccafb9d75be0248e67ee6c688fd6cee5/69585/hacktober-fest-banner.png 200w,\n/static/ccafb9d75be0248e67ee6c688fd6cee5/497c6/hacktober-fest-banner.png 400w,\n/static/ccafb9d75be0248e67ee6c688fd6cee5/ee604/hacktober-fest-banner.png 800w,\n/static/ccafb9d75be0248e67ee6c688fd6cee5/31987/hacktober-fest-banner.png 1000w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Hridayesh Sharma","github":"vyasriday","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.