From a4d65c550930c869360e869eca08a4b1a5ce382c Mon Sep 17 00:00:00 2001
From: Laura Beatris <48022589+LauraBeatris@users.noreply.github.com>
Date: Sun, 7 Apr 2024 17:20:19 -0300
Subject: [PATCH] feat(docs): Add design for Next.js

---
 docs/malta.config.json                        |  4 +-
 docs/pages/communication/credentials/index.md |  2 +-
 docs/pages/communication/use-cases/index.md   |  2 +-
 docs/pages/design/next/index.md               | 25 +++++++
 docs/pages/design/node/index.md               | 73 +++++++++++++++++++
 docs/pages/research/stytch/index.md           |  2 -
 6 files changed, 102 insertions(+), 6 deletions(-)
 create mode 100644 docs/pages/design/next/index.md
 create mode 100644 docs/pages/design/node/index.md

diff --git a/docs/malta.config.json b/docs/malta.config.json
index b84b639..5a34007 100644
--- a/docs/malta.config.json
+++ b/docs/malta.config.json
@@ -14,8 +14,8 @@
     {
       "title": "Design",
       "pages": [
-        ["Next.js SDK", "/design/sdk"],
-        ["Components", "/design/components"]
+        ["With Next.js", "/design/next"],
+        ["With Node.js", "/design/node"]
       ]
     },
     {
diff --git a/docs/pages/communication/credentials/index.md b/docs/pages/communication/credentials/index.md
index 11bef16..b9545d2 100644
--- a/docs/pages/communication/credentials/index.md
+++ b/docs/pages/communication/credentials/index.md
@@ -24,7 +24,7 @@ Instead of managing those credentials in-house, it's a good practice to use a th
 
 ### JSON Web Tokens
 
-Regardless the authentication protocol chose for M2M communication, it'll involves [JWT]([JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519)) at some point, therefore let's do a quick recap on it.
+Regardless the authentication protocol chose for M2M communication, it'll involves [JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519) at some point, therefore let's do a quick recap on it.
 
 #### JWT vs API Keys
 
diff --git a/docs/pages/communication/use-cases/index.md b/docs/pages/communication/use-cases/index.md
index 34be3bc..1602976 100644
--- a/docs/pages/communication/use-cases/index.md
+++ b/docs/pages/communication/use-cases/index.md
@@ -14,7 +14,7 @@ This section outlines use cases in which applications have to support for secure
 
 ### API Key Management
 
-The first scenario involves API Key Management, it behaves a bit different than Service-to-Service Tokens. When SaaS applications have their own set of APIs that need to communicate with their customer machines without using user's identity.
+The first scenario involves API Key Management, it behaves differently than Service-to-Service Tokens. When SaaS applications have their own set of APIs that need to communicate with their customer machines without using the user's identity.
 
 A set of API keys are generated from the SaaS application which can then be sent from the customer's API request via a HTTP header.
 
diff --git a/docs/pages/design/next/index.md b/docs/pages/design/next/index.md
new file mode 100644
index 0000000..87b72b8
--- /dev/null
+++ b/docs/pages/design/next/index.md
@@ -0,0 +1,25 @@
+---
+title: "Design - Next.js"
+---
+
+# M2M auth with Next.js
+
+Design proposal on how to perform M2M auth for a SaaS applications built with Next.js that exposes route handlers for external clients.
+
+### UI Component
+
+Provide a component for keys management, eliminating the need for developers to directly interact with the authorization server to build the UI from scratch.
+
+```tsx
+import { KeysManager } from '@clerk/nextjs';
+
+export default function Page() {
+  return <KeysManager />;
+}
+```
+
+TODO:
+- How to handle user identity protected routes vs key protected routes
+- How to protect route handlers without using middleware
+- How to expose session data on `auth`
+- How to expose utilities outside of the component to handle keys, eg: Hooks, server actions
diff --git a/docs/pages/design/node/index.md b/docs/pages/design/node/index.md
new file mode 100644
index 0000000..2a9474a
--- /dev/null
+++ b/docs/pages/design/node/index.md
@@ -0,0 +1,73 @@
+---
+title: "Design - Node.js"
+---
+
+# M2M auth with Node.js
+
+Design proposal on how to perform M2M auth for SaaS applications built with Node.js that expose API endpoints for external clients.
+
+We'll use Clerk as the auth provider for this example. Although Clerk don't expose M2M authentication at the time of writing this, the goal is to showcase how this would fit their product and also integrate with [a component approach using Next.js](../next/).
+
+### API Endpoints
+
+#### Creating keys
+
+This example is only providing the key name as metadata, but other properties might be needed as well for further customization, such as:
+- Roles, for access control
+- Expiration time
+- Owner ID: Often this will be the user ID from the current session. If you're already using an auth provider like Clerk, it should be able to include it for you.
+
+For reference, [Unkey](https://unkey.com) is a service for key management which provides further customization, such as rate limiting per key.
+
+// TODO - This endpoint needs to be protected based on the user's identity, so that authenticated users cannot create keys.
+
+```ts
+app.post('/create-key', async (req, res) => {
+  try {
+    const key = await clerkClient.createKey({
+      name: req.body.name
+    })
+
+    res.json(key)
+  } catch (error) {
+    res.json({ error: error.message })
+  }
+})
+```
+
+The key should already be associated with your application client ID, so you don't have to [programmatically create it like with Okta](https://developer.okta.com/blog/2018/06/06/node-api-oauth-client-credentials#register-clients-on-the-fly).
+
+For security, the hashed key should be returned in the response. When attempting to verify the API Key, then the `key` argument provided should be hashed and compared to the stored hashed key. If they match, then the API Key is valid.
+
+#### Protecting API endpoints with keys
+
+```js
+app.post('/protected-with-key', async (req, res) => {
+  const authHeader = req.headers["authorization"]
+  const key = authHeader?.toString().replace("Bearer ", "");
+
+  if (!key) {
+    return res.status(401).send("Unauthorized")
+  }
+
+  try {
+    const { error } = await clerkClient.verifyKey(key)
+
+    if (error) {
+      return res.status(500).send("Internal Server Error")
+    }
+
+    res.json({ protected: true })
+  } catch (error) {
+    res.json({ error: error.message })
+  }
+})
+```
+
+The above could also be integrated with a middleware instead of declaring for each protected endpoint.
+
+Another point to validate is how this would conflict with the existing [`ClerkExpressRequireAuth` Express middleware](https://clerk.com/docs/backend-requests/handling/nodejs).
+
+// TODO
+- Perhaps another middleware could be created to handle this. Eg: `ClerkExpressRequireKey`
+- How this will be exposed in the session?
diff --git a/docs/pages/research/stytch/index.md b/docs/pages/research/stytch/index.md
index a901beb..a790a42 100644
--- a/docs/pages/research/stytch/index.md
+++ b/docs/pages/research/stytch/index.md
@@ -32,8 +32,6 @@ The API call returns `client_id` and `client_secret` credentials to be exchanged
 
 Permissions can be enforced by specifying `scopes` in which is going to be contained in the returned `access_token`.
 
-An application has to call this API endpoint in order to surface credentials for usage in other external services.
-
 ### Calling Stytch's `/oauth2/token` endpoint to retrieve access token
 
 ```bash