Fix issue 33615

files/en-us/glossary/federated_identity/index.md

@@ -0,0 +1,30 @@
+---
+title: Federated identity
+slug: Glossary/Federated_identity
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+A **federated identity** system is one in which an {{glossary("identity provider", "identity provider (IdP)")}} acts as an intermediary between users and {{glossary("relying party", "relying parties")}}, enabling a user to use a single set of {{glossary("credential", "credentials")}} to authenticate with a number of different relying parties.
+
+Traditionally, on the web, a user will sign into a website with a username and a password, and the password is verified by the website against a (properly {{glossary("hash", "hashed")}} and {{glossary("salt", "salted")}}) copy stored on the website's backend.
+
+In this model, if users have multiple accounts with different websites, they have to remember many passwords, and this encourages bad password practices such as using the same password for multiple accounts.
+
+In a federated identity system, an IdP:
+
+- manages a user's credentials and can authenticate users
+- is trusted by multiple websites to make assertions about a user's identity.
+
+A user can then authenticate with the IdP, which will return a token to the user's browser if authentication is successful. The user's browser will send the token to the website, which can verify that it was issued by the IdP. If the verification succeeds, the website can sign the user in.
+
+Federated identity is often provided as a service by corporations: for example, users who have Google, Microsoft, or Facebook accounts can use them to sign in to many websites. Websites typically have to implement a process for verifying tokens that is specific to an identity provider. However, open standards such as [OpenID](https://en.wikipedia.org/wiki/OpenID), [OAuth](https://en.wikipedia.org/wiki/OAuth), and [SAML](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) are widely used in the implementation of federated identity systems.
+
+Although federated identity makes logging into multiple different accounts much easier for users and can greatly improve security, it can have serious implications for a user's privacy. If not carefully designed, a federated identity system can allow identity providers to track users across the web as they sign into multiple different sites. Early federated identity systems on the web were built on technologies such as third-party cookies, which are intrinsically privacy-invasive. As these technologies are being deprecated by browsers, new approaches are needed. The [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API) provides a standardized privacy-preserving mechanism for federated identity on the web.
+
+## See also
+
+- {{glossary("Relying party")}}
+- {{glossary("Identity provider")}}
+- [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API)

files/en-us/glossary/identity_provider/index.md

@@ -0,0 +1,19 @@
+---
+title: Identity provider (IdP)
+slug: Glossary/Identity_provider
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+An **identity provider** (IdP) is an entity in a {{glossary("federated identity")}} system that manages a user's {{glossary("credential", "credentials")}} and can {{glossary("authentication", "authenticate")}} users.
+
+In federated identity systems, {{glossary("relying party", "relying parties")}}, that need to control access to a resource (for example, a website deciding whether to sign a user in) outsource the act of authenticating users to a third party, which they trust to make authentication decisions. These third parties are called identity providers.
+
+Examples of identity providers on the web include Google, Microsoft, and Facebook. This enables websites to allow users to sign in using the user's Google, Microsoft, or Facebook account.
+
+## See also
+
+- {{glossary("Federated identity")}}
+- {{glossary("Relying party")}}
+- [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API)

files/en-us/glossary/relying_party/index.md

@@ -0,0 +1,16 @@
+---
+title: Relying party
+slug: Glossary/Relying_party
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+A **relying party** is an entity that needs to control access to a resource and, to do so, needs to {{glossary("authentication", "authenticate")}} other entities that are trying to access that resource. On the web, a relying party is usually a website that allows users to sign in and needs to authenticate users (for example by checking a password) before deciding whether to grant them access.
+
+The website _relies on_ the validity of the credentials the browser presents when it grants access to its resources.
+
+## See also
+
+- {{glossary("Federated identity")}}
+- {{glossary("Identity provider")}}

files/en-us/glossary/salt/index.md

@@ -0,0 +1,25 @@
+---
+title: Salt
+slug: Glossary/Salt
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+In cryptography, **salt** is random data added to a password before it is {{glossary("hash", "hashed")}}. This makes it impossible for an attacker to derive passwords from their hashes using precomputed tables of passwords and the corresponding hashes.
+
+Passwords should never be stored in their plaintext form, because of the risk that an attacker might break into the database where they are stored. Typically, the password is hashed, and the resulting hash is stored. If the hash function is cryptograpically secure, then even if an attacker can get access to the stored hashes, it is impractical for them to reverse the function.
+
+To derive a password from a hash, attackers can look up the password corresponding to a hash in a precomputed table (also known as a [rainbow table](https://en.wikipedia.org/wiki/Rainbow_table)) mapping possible passwords to their hashes:
+
+| Password | Hash        |
+| -------- | ----------- |
+| pa55w0rd | 56965E2A... |
+| abcdef   | BEF57EC7... |
+| letmein  | 1C8BFE8F... |
+
+Although these tables may be very large, such attacks can be effective because table lookup is a fast operation.
+
+Adding random salt to passwords before hashing them stops this attack from working because the hash is not calculated based on the password alone but on the password combined with the salt.
+
+Unlike the password, the salt does not need to be kept secret: it can be stored alongside the salted and hashed password in the server's database.