Merge branch 'master' of github.com:FusionAuth/fusionauth-site into d…

…evelopment

# Conflicts:
#	astro/src/content/docs/release-notes/index.mdx
#	astro/src/pages/docs/quickstarts/quickstart-sections.ts

astro/src/content/blog/grammarly-proves-ciam-not-optional.mdx

@@ -0,0 +1,61 @@
+---
+publish_date: 2023-10-26
+title: Grammarly's OAuth mistakes
+description: Grammarly's OAuth mistakes and what they mean for you
+authors: Dan Moore
+image: /img/blogs/grammarly-oauth/grammarlys-epic-oauth-fail.png
+categories: News
+tags: tokens, security, ciam, mistakes
+excerpt_separator: "{/* more */}"
+---
+import ValidatingTokens from "../../diagrams/blog/grammarly-oauth/validating-tokens.astro";
+
+Yesterday, a [security firm released news](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts) about three different exploits, all related to social logins and token verification. The security firm ethically and responsibly raised the issues with the companies. The vulnerabilities are now fixed, but more sites may be affected according to the report.
+
+{/* more */}
+
+## Affected Applications
+
+By the way, these affected applications are not small time. From the article:
+
+* "Vidio is an online video streaming platform with 100M monthly active users."
+* "Bukalapak is one of the largest and most prominent eCommerce platforms in Indonesia with 150 million users."
+* Grammarly is probably the most widely known victim, with "30 million daily users".
+
+These are companies with millions of active users and hundreds or thousands of employees. These are not startups in a garage. Yet for all three, "Login With Facebook" was insecurely implemented in such a way that user account takeover was a real possibility.
+
+I'm not going to dig into the details in this post. [The article](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts) does a great job of that, including walking through how account takeover could be achieved.
+
+However, one lesson from the post is that whenever you are using OAuth tokens, you must always:
+
+* validate the signature of the token, preferably by using a library or introspection
+* validate the claims of the token
+
+Here's a diagram displaying how to verify tokens.
+
+<ValidatingTokens alt={"Token validation after a grant."}/>
+
+You have to validate every token, every time, including checking the signature. This is true for any OAuth grant, including those defined by OIDC. If you want to learn more, [our article on secure signed JWTs](/articles/tokens/building-a-secure-jwt#consuming-a-jwt) goes into detail.
+
+![Verify those tokens.](/img/blogs/grammarly-oauth/verify-tokens-meme.png)
+
+## Securing Your Users Is Not Optional
+
+These breaches clearly demonstrate using proven customer identity and access management (CIAM) tools is non-optional today.
+
+Building on standards is great, but it isn't enough. A homegrown misimplementation of the standards has negative effects on your brand. Over [100 comments on HackerNews](https://news.ycombinator.com/item?id=38009291) about an article covering a security breach of yours is not great. But more importantly it impacts your users and their data. Again from the article:
+
+> "...the web editor [the compromised component] at Grammarly.com stores the data directly within Grammarly's account, which means an account takeover would give an attacker access to the victim’s stored documents. I myself am using Grammarly’s web editor for help as I've been writing this blog and writing emails, messages and documents in general."
+
+An account takeover at Grammarly, *thankfully entirely avoided per the security firm*, would have in some cases allowed an attacker to access users' private documents.
+
+Think of **your users' data being accessible** because of a mistake a developer made when implementing "Login With Facebook". I don't know about you, but this gives me the chills.
+
+CIAM is non-negotiable now. Users want to log in from multiple devices. They want to access their profile data and all the functionality your applications offer easily and securely. They may be on a phone today and a computer tomorrow. They want to use Facebook to log in, or Google, or passkeys, or [magic links](/articles/identity-basics/magic-links). Any obstacle you put in front of them will frustrate them.
+
+But CIAM and user security isn't a core competency of most engineering teams, whether at a small company or a large one like those above. The standards are publicly available for all to implement, however they are complex. They can easily be implemented incorrectly as demonstrated by these issues. Using a standalone, hardened, secured CIAM system like FusionAuth protects your users. FusionAuth regularly undergoes outside review and penetration testing. The engineering team thinks about the security ramifications every working day (and most weekends!).
+
+The speedup in feature delivery and the outsourcing of authentication and authorization related maintenance are merely bonuses. Check out [our quickstarts to see how easy it is to integrate FusionAuth into your technology stack](/fusionauth.io/docs/quickstarts/).
+
+A secure CIAM doesn't have to break the bank, either. You can use FusionAuth for free if you [download](/download) and run it yourself, or you can [buy premium features, support and hosting](/pricing) if those meet your needs. 
+