diff --git a/src/css/style.css b/src/css/style.css index 2a0a410..1e4a641 100644 --- a/src/css/style.css +++ b/src/css/style.css @@ -203,3 +203,7 @@ pre { margin-top: 25px; padding: 0 10px; } + +.justified { + text-align: justify; +} diff --git a/src/flow/code-3.html b/src/flow/code-3.html index cc27239..b836101 100644 --- a/src/flow/code-3.html +++ b/src/flow/code-3.html @@ -1,10 +1,9 @@ - - OAuth 2.0 Playground + OAuth 2.0 Playground - Authorization Code Flow (3/3) @@ -16,13 +15,12 @@ -
-

Authorization Code Flow

+

Authorization Code Flow

1 @@ -36,7 +34,6 @@ 3
-
Build the authorization URL and redirect the user to the authorization server @@ -57,13 +54,12 @@
3. Exchange the code for token

Now that we have the authorization code, we can exchange it for an access token. This is done by sending a POST request to the token endpoint.

-

With body data

+

With body data:

-
Let's break it down...
+ Let's break it down...

  • -

    -

    +

    The token endpoint URL

  • @@ -86,19 +82,79 @@ access token.

-
-
- [ Take me home ] +
@@ -148,7 +204,12 @@ }) .then(response => response.json()) .then(data => { + $("#token-result").show(); $("#token").text(JSON.stringify(data, null, 2)); + $("#get-token-btn").hide(); + $([document.documentElement, document.body]).animate({ + scrollTop: $("#token-result").offset().top + }, 1000); }) .catch(error => { console.error('Error fetching the token:', error); diff --git a/src/index.html b/src/index.html index e2deb09..f0501e2 100644 --- a/src/index.html +++ b/src/index.html @@ -48,7 +48,7 @@
Authorization Code Flow
-

OAuth 2.0 protocol designed for web applications that can securely store client secrets. +

OAuth 2.0 protocol designed for web applications that can securely store client secrets. The application directs users to an authorization server to log in and grant permissions. Upon consent, the server issues an authorization code. The application then exchanges this code for an access token in a server-to-server request, using its client ID, client secret, and redirection URI. This flow ensures the access token is never directly @@ -66,7 +66,7 @@

PKCE
-

Proof Key for Code Exchange is a security protocol for the OAuth 2.0 authorization framework, designed to prevent +

Proof Key for Code Exchange is a security protocol for the OAuth 2.0 authorization framework, designed to prevent interception attacks in the authorization code flow. It's especially crucial for mobile or single-page applications where storing a client secret securely is challenging. In PKCE, the client creates a dynamic "code verifier" and its transformed "code challenge." The server remembers this challenge, and when the authorization code is exchanged for an @@ -84,7 +84,7 @@

Device Authorization Grant
-

OAuth 2.0 flow optimized for devices that either lack a browser or have limited input +

OAuth 2.0 flow optimized for devices that either lack a browser or have limited input capabilities, such as smart TVs, game consoles, and certain IoT devices. In this flow, the device makes a request to the authorization server and receives a unique user code and a verification URL. The user then accesses this URL on a separate device with a browser, like a smartphone or computer, and enters the user code. After successfully logging in @@ -103,7 +103,7 @@

CIBA
-

Client Initiated Backchannel Authentication is a protocol extension for OAuth 2.0, tailored for scenarios where +

Client Initiated Backchannel Authentication is a protocol extension for OAuth 2.0, tailored for scenarios where the client, such as a financial institution or IoT device, initiates the authentication process without direct user interaction on the client's platform. This is useful for "decoupled" authentication experiences, where, for instance, a user might authenticate on their smartphone when prompted by a smart TV app. In CIBA, once the client requests @@ -123,7 +123,7 @@

WebAuthN
-

This protocol leverages public key cryptography and allows users to authenticate using biometrics, mobile devices, or +

This protocol leverages public key cryptography and allows users to authenticate using biometrics, mobile devices, or FIDO security keys, instead of traditional passwords. When a user registers with a website, a unique key pair is generated: the private key stays securely on the user's device, and the public key is registered with the website. For subsequent logins, the website challenges the user to prove ownership of the private key, typically by prompting for a