Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Estelle Weyl <estelle@openwebdocs.org>
  • Loading branch information
wbamberg and estelle committed May 24, 2024
1 parent 787f83f commit fcf8de6
Show file tree
Hide file tree
Showing 3 changed files with 5 additions and 5 deletions.
6 changes: 3 additions & 3 deletions files/en-us/glossary/federated_identity/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,11 +17,11 @@ In a federated identity system, an _identity provider_:
- 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 was successful. The user's browser will send the token to the website, who can verify that it was issued by the IdP. If the verification succeeds, the website can sign the user in.
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 into many websites. Websites typically have to implement a process for verifying tokens that's 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.
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 life 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 try to sign into sites. Early federated identity systems on the web were built on technologies such as third-party cookies, which are intrinsically privacy-invasive, and as these technologies have been deprecated by browsers, new approaches are needed. The [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API) aims to standardize a privacy-preserving mechanism for federated identity on the web.
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

Expand Down
2 changes: 1 addition & 1 deletion files/en-us/glossary/relying_party/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ page-type: glossary-definition

{{GlossarySidebar}}

A **relying party** is an entity that needs to control access to some resource, and to do so needs to authenticate other entities that are trying to access the 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.
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.

Expand Down
2 changes: 1 addition & 1 deletion files/en-us/glossary/salt/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,6 @@ To derive a password from a hash, attackers can look up the password correspondi

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 over the password itself, but on the password combined with the salt.
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.

0 comments on commit fcf8de6

Please sign in to comment.