fixes

content/openid-connect-vs-oauth2/index.md

@@ -7,17 +7,25 @@ category: "programming"
 author: "Darko Bozhinovski"
 ---
 
+## Table of Content
+- [Introduction](#introduction)
+- [What's OAuth 2.0?](#whats-oauth-20)
+- [What's OpenID Connect?](#whats-openid-connect)
+- [The differences between OpenID Connect and OAuth](#the-differences-between-openid-connect-and-oauth)
+- [How to choose between OpenID Connect and OAuth](#how-to-choose-between-openid-connect-and-oauth)
+- [Conclusion](#conclusion)
+
 
 ## Introduction
 
 As developers, we can agree that authentication (and authorization) are a cornerstone of most modern software. It's pretty hard to imagine the Facebooks and Googles of the world without being able to confirm who you are as a user of that service (authentication) and what data that service is able to access (authorization).
-That said, the underlying standards that drive the concepts of authentication and authorization are often misunderstood and confusing. In this piece, we'll try to demystify those concepts and the accepted standards embodying them—OpenID Connect and OAuth 2.
 
+That said, the underlying standards that drive the concepts of authentication and authorization are often misunderstood and confusing. In this piece, we'll try to demystify those concepts and the accepted standards embodying them—OpenID Connect and OAuth 2.
 
 ## What's OAuth 2.0?
 
 
-At its core, [OAuth2](https://oauth.net/2/) is an authorization framework that has become the industry standard for authorizing third-party access to user information on a service without sharing their user credentials themselves (most commonly, passwords).
+At its core, [OAuth2](https://oauth.net/2/) is an *authorization* framework that has become the industry standard for authorizing third-party access to user information on a service without sharing their user credentials themselves (most commonly, passwords).
 
 It revolves around the concept of granting permissions or "tokens" to third-party applications, allowing delegated authorization. These tokens provide limited access to the user's data, ensuring that the user's credentials remain safe and that their information is only accessed as per their explicit consent.
 
@@ -34,13 +42,15 @@ Looking under the hood into the code, we can see that OAuth2 governs things like
 
 ## What's OpenID Connect?
 
-[OpenID Connect](https://openid.net/developers/how-connect-works/) is an open standard authentication protocol built on top of the OAuth 2.0 authorization framework. It allows developers to authenticate users across websites mobile apps and applications without needing to own and manage password credentials. Apart from being OAuth2 compliant Google is also an OpenID provider.
+[OpenID Connect](https://openid.net/developers/how-connect-works/) is an open standard authentication protocol built on top of the OAuth 2.0 authorization framework. It allows developers to authenticate users across websites mobile apps and applications without needing to own and manage password credentials.
+
+For example, apart from being OAuth2 compliant Google is also an OpenID provider.
 
-The OpenID Connect has two flows.
+OpenID Connect has two flows.
 - Implicit flow
 - Authorization code flow
 
-Both are based on OAuth2, but also return an ID token(which is a JSON Web Token) along with an access token, now enabling both authentication and authorization. You can learn more about
+Both are based on OAuth2, but also return an ID token(which is a JSON Web Token) along with an access token, enabling both authentication and authorization. You can learn more about the differences between the [Implicit flow and Authorization code flow here](https://supertokens.com/blog/authorization-code-flow-with-pkce).
 
 In essence, OpenID Connect provides an additional identity layer on top of OAuth 2.0, enabling clients (websites or applications) to verify the identity of a user.
 
@@ -70,10 +80,10 @@ While OAuth 2.0 and OpenID Connect are closely related and often used together,
 
 While it's possible to shoehorn OAuth as an authentication mechanism, it comes with some unexpected security issues. As this [StackExchange post](https://security.stackexchange.com/questions/37818/why-use-openid-connect-instead-of-plain-oauth2) aptly puts it:
 
-Relying on plain OAuth 2.0 for authentication is dangerous if you (the client) are just trusting ANY valid access token you receive that's associated with that user as a reliable indicator that you're receiving the request from the actual user without knowing whether that access token was generated by the user trying to log into your site or if it was generated by the user logging into some other (malicious) website/app.
-With OpenID Connect, you can just look inside the JWT ID token provided by incoming requests and see if that token was generated by the user logging into your app or if they were logging into some other web app.
+> Relying on plain OAuth 2.0 for authentication is dangerous if you (the client) are just trusting ANY valid access token you receive that's associated with that user as a reliable indicator that you're receiving the request from the actual user without knowing whether that access token was generated by the user trying to log into your site or if it was generated by the user logging into some other (malicious) website/app. </br>
+> With OpenID Connect, you can just look inside the JWT ID token provided by incoming requests and see if that token was generated by the user logging into your app or if they were logging into some other web app.
 
-This discussion ultimately ends up as Authentication vs. Authorization: If your application needs to request access to user data and authenticate the user's identity, OpenID Connect is the way to go. OAuth 2.0 alone does not provide mechanisms to authenticate users—it assumes that authentication is performed by the application itself or through another mechanism.
+This discussion ultimately ends up as **Authentication vs. Authorization**: If your application needs to request access to user data and authenticate the user's identity, OpenID Connect is the way to go. OAuth 2.0 alone does not provide mechanisms to authenticate users—it assumes that authentication is performed by the application itself or through another mechanism.
 
 Understanding the differences between OpenID Connect and OAuth 2.0 is crucial for developers looking to implement secure access to resources and robust user authentication. While OAuth 2.0 lays the groundwork for secure user authorization only, OpenID Connect builds upon this foundation to provide a comprehensive authentication and identity layer. The choice between them depends on your application's specific needs - whether you require simple authorization or also need to authenticate user identities.
 
@@ -86,7 +96,7 @@ When developing a web or mobile application, you might decide to integrate OpenI
 
 2. **Authorization (What can this user do?):** If your application needs to access a user's data from another service or perform actions on behalf of the user without necessarily authenticating their identity, OAuth 2.0 is sufficient. It allows your application to request specific access to resources from another service without getting access to the user’s credentials.
 
-### Following that, consider the user experience:
+### Consider the user experience:
 1. **Single Sign-On (SSO):** If you aim to provide a seamless experience across multiple applications, allowing users to log in once and not have to authenticate again for access to other services, OpenID Connect is the preferred choice. It supports SSO by leveraging its authentication mechanism across different applications.
 
 2. **Consent and Trust:** OAuth 2.0’s consent mechanism can be a critical factor in how users perceive your application's trustworthiness. Being clear about what permissions your application is requesting and ensuring you only ask for what’s necessary can improve user trust and compliance. OpenID Connect adds a layer of user authentication, which can further enhance trust by securely verifying user identity.