add videos

kentcdodds · kentcdodds · commit c1e5fc6893af · 2025-09-24T16:31:11.000-06:00
diff --git a/exercises/01.discovery/01.problem.cors/README.mdx b/exercises/01.discovery/01.problem.cors/README.mdx
@@ -1,5 +1,7 @@
 # CORS
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/cors-fibqe" />
+
 👨‍💼 In our MCP server's case, users will always be accessing us from either a different domain or a desktop application. This means every single request is cross-origin by nature, making CORS headers absolutely essential for our server to function at all.
 
 If we can't handle cross-origin requests properly, users will encounter frustrating errors and won't be able to access the server's capabilities from their preferred applications or domains. The problem is: how do we enable secure cross-origin communication while maintaining the security standards that protect our users and server?
diff --git a/exercises/01.discovery/01.solution.cors/README.mdx b/exercises/01.discovery/01.solution.cors/README.mdx
@@ -1,5 +1,7 @@
 # CORS
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/cors-fibqe/solution" />
+
 👨‍💼 Excellent work! Now our users can connect to our server from any domain without encountering frustrating CORS policy errors.
 
 This improvement means users get seamless access to our MCP server's capabilities regardless of where they're connecting from. Whether they're using VS Code, a web application, or any other MCP client, the connection just works. This is exactly what users expect from a modern, accessible MCP server.
diff --git a/exercises/01.discovery/02.problem.as/README.mdx b/exercises/01.discovery/02.problem.as/README.mdx
@@ -1,5 +1,7 @@
 # Auth Server Metadata
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/auth-server-metadata-g2r2y" />
+
 👨‍💼 Now that clients can connect to our MCP server from any domain, they need to be able to discover how to authenticate with our system. When clients want to access protected resources or perform actions that require authentication, they need to know where to go and what methods are available.
 
 The problem is: how do we provide clients with the information they need to authenticate with our OAuth server? Without this metadata, clients will be stuck because they can't figure out authentication endpoints and supported features.
diff --git a/exercises/01.discovery/02.solution.as/README.mdx b/exercises/01.discovery/02.solution.as/README.mdx
@@ -1,5 +1,7 @@
 # Auth Server Metadata
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/auth-server-metadata-g2r2y/solution" />
+
 👨‍💼 Fantastic progress! Now, clients can seamlessly discover how to authenticate with our system by accessing the standardized `/.well-known/oauth-authorization-server` endpoint. This means any MCP-compliant client can automatically find out where to register, authorize, and obtain tokens—removing guesswork and enabling smooth, standards-based integration.
 
 By relaying the OAuth server's metadata, we've made our MCP server a true authentication discovery hub. This empowers users to connect their tools and applications with confidence, knowing they have all the information needed for secure authentication.
diff --git a/exercises/01.discovery/03.problem.pr/README.mdx b/exercises/01.discovery/03.problem.pr/README.mdx
@@ -1,5 +1,7 @@
 # Protected Resource
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/protected-resource-8kue7" />
+
 👨‍💼 For our journaling app it's crucial that clients can discover how to interact with our resource server in a standards-compliant way. The Model Context Protocol (MCP) and OAuth require that we expose a public metadata endpoint so that any client can learn how to authenticate and what endpoints are available. This endpoint must be accessible to everyone, without requiring authentication, because it's the first step in the OAuth discovery process.
 
 But not all protected resources are the same! In a large system, you might have multiple APIs or services, each with its own protected data—think: user profiles, journal entries, or analytics. Each of these can be considered a separate "protected resource" in OAuth terms. To support this, the OAuth and MCP specifications allow for multiple resource metadata endpoints, each describing a different protected resource.
diff --git a/exercises/01.discovery/03.solution.pr/README.mdx b/exercises/01.discovery/03.solution.pr/README.mdx
@@ -1,5 +1,7 @@
 # Protected Resource
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/protected-resource-8kue7/solution" />
+
 👨‍💼 Outstanding achievement! Now, any client can discover how to interact with our journaling resource server in a standards-compliant way. By exposing the public `/.well-known/oauth-protected-resource/mcp` metadata endpoint, we've made it possible for clients to programmatically learn how to authenticate and which authorization servers to use—without any guesswork or manual configuration.
 
 This means that as our system grows, each protected resource (like user profiles, journal entries, or analytics) can have its own discoverable endpoint, making integration seamless for all clients. Users benefit from a smoother onboarding experience, and developers can confidently build on top of our platform knowing that discovery is simple and future-proof.
diff --git a/exercises/01.discovery/FINISHED.mdx b/exercises/01.discovery/FINISHED.mdx
@@ -1,5 +1,7 @@
 # Metadata Discovery
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/outro-to-metadata-discovery-vmqxq" />
+
 Congratulations! You've completed the first step in making your MCP server discoverable and accessible to any standards-compliant client.
 
 In this exercise, you:
diff --git a/exercises/01.discovery/README.mdx b/exercises/01.discovery/README.mdx
@@ -1,5 +1,7 @@
 # Metadata Discovery
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/intro-to-metadata-discovery-7idpi" />
+
 Modern applications need a way for clients to discover how to authenticate and interact with servers securely. In the Model Context Protocol (MCP), this is achieved through standardized metadata endpoints that describe both the resource server (your MCP server) and its associated authorization server.
 
 Without this discovery mechanism, clients would have to guess or hardcode authentication details, leading to brittle integrations and poor user experience.
diff --git a/exercises/02.init/01.problem.authenticate/README.mdx b/exercises/02.init/01.problem.authenticate/README.mdx
@@ -1,5 +1,7 @@
 # Authenticate Header
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/authenticate-header-0n13b" />
+
 👨‍💼 In EpicMe, the `Authorization` header is the gatekeeper for every journal entry. Its job is simple but critical: make sure that only requests with valid credentials can access or change journal data. If a request doesn't include this header, it shouldn't get through—no exceptions. Once the client has an auth token, it'll send that token in the `Authorization` header. If that header doesn't exist, then we know they don't have a token and shouldn't be able to access our server.
 
 But we can help them out by telling them what they need to do to get access. This is where the `WWW-Authenticate` header comes in. It tells the client what kind of authentication is required.
diff --git a/exercises/02.init/01.solution.authenticate/README.mdx b/exercises/02.init/01.solution.authenticate/README.mdx
@@ -1,3 +1,5 @@
 # Authenticate Header
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/authenticate-header-0n13b/solution" />
+
 👨‍💼 Fantastic progress! We've just ensured that every request to our journal app is properly challenged for credentials. Now, if a client tries to access protected resources without an Authorization header, the server responds with a `401 Unauthorized` and a clear `WWW-Authenticate` header. This makes it obvious to clients what they need to do next, improving both security and user experience (while keeping us complient with the OAuth and MCP Authorization spec). Only authenticated users can move forward, keeping journal data safe and access predictable for everyone.
diff --git a/exercises/02.init/02.problem.params/README.mdx b/exercises/02.init/02.problem.params/README.mdx
@@ -1,5 +1,7 @@
 # Auth Params
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/auth-params-vilat" />
+
 👨‍💼 In EpicMe, when a user tries to access a protected journal entry, it's not enough to simply block them. We need to let them what to do about it. If a request is missing the right credentials, the server should respond with a `WWW-Authenticate` header that includes extra details, called auth params, so the client understands what went wrong and how to fix it.
 
 For example, if a robot tries to fetch `/api/lemonade` without the right credentials, the response should include a realm and a resource_metadata parameter:
diff --git a/exercises/02.init/02.solution.params/README.mdx b/exercises/02.init/02.solution.params/README.mdx
@@ -1,3 +1,5 @@
 # Auth Params
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/auth-params-vilat/solution" />
+
 👨‍💼 Great job! We've just made our API much more helpful for clients by including detailed auth params in the `WWW-Authenticate` header when access is denied. Now, when a request is missing the right credentials, the response not only blocks access but also provides a `realm` and a `resource_metadata` URL. This gives clients clear guidance on what resource they're trying to access and where to find more information, making it easier for them to recover and try again. This improvement leads to a smoother integration experience and helps clients build smarter, more user-friendly apps.
diff --git a/exercises/02.init/FINISHED.mdx b/exercises/02.init/FINISHED.mdx
@@ -1,3 +1,5 @@
 # Initialize OAuth Flow
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/outro-to-initialize-o-auth-flow-5lxa5" />
+
 Woo! You did it! You've secured our MCP server by requiring the `Authorization` header and returning a `WWW-Authenticate` header with helpful details. This blocks unauthorized access and guides clients on how to authenticate.
diff --git a/exercises/02.init/README.mdx b/exercises/02.init/README.mdx
@@ -1,5 +1,7 @@
 # Initialize OAuth Flow
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/intro-to-authenticate-header-xosav" />
+
 Modern web applications need a way to securely identify users and protect resources. The first step in this process is checking for an `Authorization` header on incoming requests. This is foundational for any OAuth flow.
 
 In this exercise, you'll:
diff --git a/exercises/03.auth-info/01.problem.introspect/README.mdx b/exercises/03.auth-info/01.problem.introspect/README.mdx
@@ -1,5 +1,7 @@
 # Introspect
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/introspect-pjgp6" />
+
 👨‍💼 Ok, so we've got the user's auth token, but what do we do with it? Our server needs to know:
 
 - Is the token valid?
diff --git a/exercises/03.auth-info/01.solution.introspect/README.mdx b/exercises/03.auth-info/01.solution.introspect/README.mdx
@@ -1,3 +1,5 @@
 # Introspect
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/introspect-pjgp6/solution" />
+
 👨‍💼 Super! You've successfully implemented token introspection, which transforms anonymous tokens into rich user context. Now our MCP server can identify who each user is and understand their permissions, enabling personalized experiences and proper access control.
diff --git a/exercises/03.auth-info/02.problem.error/README.mdx b/exercises/03.auth-info/02.problem.error/README.mdx
@@ -1,5 +1,7 @@
 # Invalid Token Error
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/invalid-token-error-lm5cu" />
+
 👨‍💼 When clients provide an authentication token that turns out to be invalid or expired, they need clear feedback about what went wrong. Without proper error messaging, users might think the service is broken or get confused about why their request failed.
 
 The current error response doesn't distinguish between "no token provided" and "invalid token provided." This makes it harder for clients to provide helpful guidance to clients about what they need to do next.
diff --git a/exercises/03.auth-info/02.solution.error/README.mdx b/exercises/03.auth-info/02.solution.error/README.mdx
@@ -1,5 +1,7 @@
 # Invalid Token Error
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/invalid-token-error-lm5cu/solution" />
+
 👨‍💼 Excellent! We've enhanced our error handling to provide clear, actionable feedback when clients provide invalid tokens. Now users get specific guidance about token expiration instead of generic error messages, making the authentication experience much more user-friendly.
 
 This improvement means clients can distinguish between "no token provided" and "invalid token provided," enabling them to show appropriate messages like "Please log in again" when tokens expire.
diff --git a/exercises/03.auth-info/03.problem.active/README.mdx b/exercises/03.auth-info/03.problem.active/README.mdx
@@ -1,5 +1,7 @@
 # Token Active
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/token-active-zbbw4" />
+
 👨‍💼 When we introspect an auth token, the introspection endpoint will return whether the token is currently active (because tokens can be revoked or expired) and we need to check for that in our resolution callback.
 
 The solution is to always verify that a token is active before trusting any of its claims. OAuth 2.0 introspection responses include an `active` property that tells us exactly this.
diff --git a/exercises/03.auth-info/03.solution.active/README.mdx b/exercises/03.auth-info/03.solution.active/README.mdx
@@ -1,3 +1,5 @@
 # Token Active
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/token-active-zbbw4/solution" />
+
 👨‍💼 Great job. Really checking the `active` property was just a simple change, but making it typesafe with discriminated unions was a nice bonus!
diff --git a/exercises/03.auth-info/FINISHED.mdx b/exercises/03.auth-info/FINISHED.mdx
@@ -1,3 +1,5 @@
 # Auth Info
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/outro-to-auth-info-rh757" />
+
 Great work on this. You now know how to go from an auth token to user-specific information that will help you identify the user and their permissions in your server. Now on to getting that information into your MCP tools!
diff --git a/exercises/03.auth-info/README.mdx b/exercises/03.auth-info/README.mdx
@@ -1,5 +1,7 @@
 # Auth Info
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/intro-to-auth-info~3k9ug" />
+
 So the client sends your resource server a token. Sometimes this is enough, but often you need to be able to know who that token represents and the scopes associated to that token. This is often referred to as "introspection".
 
 In this exercise, you'll learn how to introspect tokens, handle invalid tokens, and determine if a token is active—all essential for building robust, user-friendly authentication flows in MCP servers.
diff --git a/exercises/04.user/01.problem.token/README.mdx b/exercises/04.user/01.problem.token/README.mdx
@@ -1,5 +1,7 @@
 # Client Token
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/client-token-st24u" />
+
 👨‍💼 When we make requests using `this.db` (our db client), we need to include the user's authentication token so that the server knows who the user is and what they're allowed to access.
 
 Right now the db client doesn't accept a token, so you need to update it to do so.
diff --git a/exercises/04.user/01.solution.token/README.mdx b/exercises/04.user/01.solution.token/README.mdx
@@ -1,3 +1,5 @@
 # Client Token
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/client-token-st24u/solution" />
+
 👨‍💼 Excellent work! We've successfully implemented user-specific database access by passing authentication tokens to our database client. This is a crucial step in securing our MCP server. It ensures each user only sees their own data.
diff --git a/exercises/04.user/02.problem.user/README.mdx b/exercises/04.user/02.problem.user/README.mdx
@@ -1,5 +1,7 @@
 # Require User
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/require-user-adoka" />
+
 👨‍💼 Now that we have the client authenticated with the token, let's make a utility to get the user and also provide tools and resources to retrieve the user data.
 
 🧝‍♀️ I created a resource and a tool for you, all you need to do is implement the `requireUser` utility then use that in the tool and resource. Feel free to <PrevDiffLink>check out my changes</PrevDiffLink> if you want.
diff --git a/exercises/04.user/02.solution.user/README.mdx b/exercises/04.user/02.solution.user/README.mdx
@@ -1,3 +1,5 @@
 # Require User
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/require-user-adoka/solution" />
+
 👨‍💼 Excellent work! Now clients can retrieve information about the currently logged in user.
diff --git a/exercises/04.user/FINISHED.mdx b/exercises/04.user/FINISHED.mdx
@@ -1,5 +1,7 @@
 # Using the User
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/outro-to-using-the-user-zu3bw" />
+
 Congratulations! You've successfully implemented user-specific functionality in your MCP server. You've moved from a generic MCP server into a personalized, secure system that knows who each user is and ensures they only access their own data.
 
 You also now understand how to pass authentication information through Cloudflare's context system using `ctx.props`, and then using that information to create user-specific database clients and utility functions to access it in the tools, resources, and prompts.
diff --git a/exercises/04.user/README.mdx b/exercises/04.user/README.mdx
@@ -1,5 +1,7 @@
 # Using the User
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/intro-to-using-the-user-w1w8a" />
+
 Now that we have the auth info, we need to get it into our MCP agent's context so we can make database calls with the user's token and also expose it to our tools and resources. With Cloudflare Workers, this is done through the `ctx.props` mechanism, which allows you to pass data from the request handler into your `McpAgent` instance.
 
 Example:
diff --git a/exercises/05.scopes/01.problem.check-scopes/README.mdx b/exercises/05.scopes/01.problem.check-scopes/README.mdx
@@ -1,5 +1,7 @@
 # Check Scopes
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/check-scopes-xkjqu" />
+
 👨‍💼 We're going to start adding more fine-grained control to what our MCP server can do by adding scopes. Our authorization server already supports scopes, and it makes no sense for the MCP server to show tools, resources, or prompts that the user doesn't have permission to use anyway.
 
 This is where OAuth scopes come in. They give us fine-grained control over what authenticated users can access.
diff --git a/exercises/05.scopes/01.solution.check-scopes/README.mdx b/exercises/05.scopes/01.solution.check-scopes/README.mdx
@@ -1,5 +1,7 @@
 # Check Scopes
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/check-scopes-xkjqu/solution" />
+
 👨‍💼 Excellent work! We've successfully implemented scope validation utilities that give our EpicMe journaling app fine-grained control over what authenticated users can access. Now our MCP server can check if users have the required permissions before allowing them to perform sensitive operations like reading private entries or managing tags.
 
 This improvement means users get proper access control based on their granted scopes, ensuring that personal journal data stays secure and only authorized actions are permitted. The scope validation utilities we built will be the foundation for all our permission checks going forward.
diff --git a/exercises/05.scopes/02.problem.validate-sufficient-scope/README.mdx b/exercises/05.scopes/02.problem.validate-sufficient-scope/README.mdx
@@ -1,5 +1,7 @@
 # Validate Sufficient Scope
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/validate-sufficient-scope-wwivw" />
+
 👨‍💼 Some users are authenticating with no scopes which results in having a valid token, but not enough permissions to actually do anything useful with the MCP server. It would be better if we could let them know up front that they don't have enough permissions and need a new token with the appropriate scopes.
 
 To do this, you return a `403 Forbidden` response with the appropriate `WWW-Authenticate` header:
diff --git a/exercises/05.scopes/02.solution.validate-sufficient-scope/README.mdx b/exercises/05.scopes/02.solution.validate-sufficient-scope/README.mdx
@@ -1,3 +1,5 @@
 # Validate Sufficient Scope
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/validate-sufficient-scope-wwivw/solution" />
+
 👨‍💼 Excellent work! Now users won't be able to access the MCP server if they don't have useful permissions.
diff --git a/exercises/05.scopes/03.problem.scope-hints/README.mdx b/exercises/05.scopes/03.problem.scope-hints/README.mdx
@@ -1,5 +1,7 @@
 # Scope Hints
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/scope-hints-p0c97" />
+
 👨‍💼 When users try to access our EpicMe journaling app without proper permissions, they need clear guidance on what scopes are available and required. Without this information, clients can't know what to request during the OAuth authorization flow, leading to failed authentication attempts and frustrated users.
 
 The solution is to provide a **scope hint** (called `scopes_supported`) in our OAuth protected resource metadata. This metadata tells clients exactly what scopes are supported and help them understand what permissions they could request from the authorization server.
diff --git a/exercises/05.scopes/03.solution.scope-hints/README.mdx b/exercises/05.scopes/03.solution.scope-hints/README.mdx
@@ -1,5 +1,7 @@
 # Scope Hints
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/scope-hints-p0c97/solution" />
+
 👨‍💼 Excellent work! We've successfully implemented scope hints that guide clients through the OAuth authorization process. Now when users encounter permission issues, their client apps can automatically discover what scopes are available and request the right permissions.
 
 This improvement means users get clear guidance on what permissions they need, eliminating confusion and failed authentication attempts. The scope hints in both the 401 Unauthorized response and the OAuth protected resource metadata ensure clients always know exactly what to request from the authorization server.
diff --git a/exercises/05.scopes/FINISHED.mdx b/exercises/05.scopes/FINISHED.mdx
@@ -1,3 +1,5 @@
 # Scopes
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/outro-to-scopes-xywcb" />
+
 Congratulations! You've successfully implemented fine-grained access control for your MCP server using OAuth scopes. Your EpicMe journaling app now provides secure, permission-based access to different features and resources.
diff --git a/exercises/05.scopes/README.mdx b/exercises/05.scopes/README.mdx
@@ -1,5 +1,7 @@
 # Scopes
 
+<EpicVideo url="https://www.epicai.pro/workshops/day-7-8-mcp-auth/intro-to-scopes-kpt4u" />
+
 When building secure MCP servers, you need fine-grained control over what authenticated users can access. OAuth scopes provide this control by allowing you to define specific permissions that clients must request and users must grant. Without proper scope validation, your MCP server might expose sensitive data or allow unauthorized operations.
 
 Think of scopes like keys to different rooms in a building. A user might have a key to the lobby (basic access) but not to the executive offices (admin functions). In our EpicMe journaling app, we want to ensure that clients can only access the data and perform the actions they're explicitly authorized for.
diff --git a/exercises/FINISHED.mdx b/exercises/FINISHED.mdx
diff --git a/exercises/README.mdx b/exercises/README.mdx
diff --git a/package.json b/package.json
