# HG changeset patch
# User Kim Alvefur <zash@zash.se>
# Date 1682760364 -7200
# Node ID 12498c0d705f80ee001b6ad0f22dd79d05a4ebdc
# Parent  32a9817c7516fd6f55e71f79c87ac5f1e701d54c
mod_http_oauth2: Reorder routes into order they happen in OAuth 2.0

Since I usually start here to remember the order of things, might as
well turn it into a mini step by step guide :)

diff -r 32a9817c7516 -r 12498c0d705f mod_http_oauth2/mod_http_oauth2.lua
--- a/mod_http_oauth2/mod_http_oauth2.lua	Fri Apr 28 13:27:06 2023 +0100
+++ b/mod_http_oauth2/mod_http_oauth2.lua	Sat Apr 29 11:26:04 2023 +0200
@@ -833,14 +833,26 @@
 module:depends("http");
 module:provides("http", {
 	route = {
-		-- User-facing login and consent view
+		-- OAuth 2.0 in 5 simple steps!
+		-- This is the normal 'authorization_code' flow.
+
+		-- Step 1. Create OAuth client
+		["POST /register"] = handle_register_request;
+
+		-- Step 2. User-facing login and consent view
 		["GET /authorize"] = handle_authorization_request;
 		["POST /authorize"] = handle_authorization_request;
 
-		-- Create OAuth client
-		["POST /register"] = handle_register_request;
+		-- Step 3. User is redirected to the 'redirect_uri' along with an
+		-- authorization code.  In the insecure 'implicit' flow, the access token
+		-- is delivered here.
 
+		-- Step 4. Retrieve access token using the code.
 		["POST /token"] = handle_token_grant;
+
+		-- Step 4 is later repeated using the refresh token to get new access tokens.
+
+		-- Step 5. Revoke token (access or refresh)
 		["POST /revoke"] = handle_revocation_request;
 
 		-- OpenID