Practice Questions

Authentication answers “Who are you?” – it is about proving identity (e.g., signing in with a username/password or via OAuth). Authorization answers “Are you allowed to do this?” – it is about permissions (e.g., can this user delete this record?).

You can have authentication without authorization – a site where every signed-in user has identical abilities only needs to know who the user is, not what they are allowed to do. You cannot meaningfully have authorization without authentication – rules about “who can do what” require knowing who the caller is.

Example of authentication: a user signs in via GitHub OAuth to prove their identity. Example of authorization: after signing in, the server checks whether the user’s ID matches the ownerId field on a document before allowing deletion.

The UI is not a security boundary. Anyone can bypass the frontend by:

• Opening the browser’s DevTools console and calling the mutation directly
• Sending a raw HTTP/WebSocket request using tools like curl or Postman
• Modifying the JavaScript in the browser to re-enable hidden buttons

If the server does not enforce the rule, a malicious user can perform any action regardless of what the UI shows or hides. UI gates are there for the user experience: they hide controls the user cannot use. Server gates are there for security: they refuse operations the user is not allowed to perform. You need both, and one does not replace the other.

The OAuth flow involves three parties:

1. Browser (client): The user clicks “Sign in with [Provider].” The browser is redirected to the OAuth provider’s authorization page.

2. OAuth provider (e.g., GitHub): Displays an authorization screen asking the user to grant permissions to the application. If the user authorizes, the provider redirects the browser back to the application’s callback URL with a temporary authorization code.

3. Application backend: Receives the callback with the temporary code. It exchanges that code for an access token by communicating server-to-server with the provider. It then uses the access token to fetch the user’s profile information, creates or updates a user record in its own database, creates a session (often via a JWT), and redirects the browser back to the app.

Note that the user’s credentials (the password) are never shared with the application. The user authenticates directly with the provider, and the application only receives a token that proves the user authorized it.

(a) Calling getCurrentUser inside the guard makes it self-contained. If the guard accepted a user parameter, every caller would have to remember to call getCurrentUser first and pass the result in. With the call inside, one call to the guard handles both authentication (“is someone signed in?”) and authorization (“is it the right person?”).

(b) The guard already loads the document from the database with ctx.db.get. Returning it lets the caller reuse the loaded document instead of reading it a second time. If the caller does not need it, the caller can ignore the return value.

©

export const rename = mutation({
  args: {
    id: v.id("documents"),
    name: v.string(),
  },
  handler: async (ctx, args) => {
    await assertDocumentOwner(ctx, args.id);
    await ctx.db.patch(args.id, { name: args.name });
  },
});

async function assertCommentAuthorAndDeletable(
  ctx: MutationCtx,
  commentId: Id<"comments">,
): Promise<Doc<"comments">> {
  const user = await getCurrentUser(ctx);
  const comment = await ctx.db.get(commentId);
  if (comment === null) {
    throw new ConvexError("Comment not found");
  }
  if (comment.authorId !== user._id) {
    throw new ConvexError("Only the author can delete this comment");
  }
  if (comment.status !== "draft") {
    throw new ConvexError("This comment can no longer be deleted");
  }
  return comment;
}

This follows the same pattern: authenticate the caller, load the document, check identity, check state, throw with a terse error message if any check fails, and return the document for the caller to reuse.

These three components conditionally render their children based on the current authentication state:

• <Authenticated> renders its children only when a user is signed in.
• <Unauthenticated> renders its children only when no user is signed in.
• <AuthLoading> renders its children only while the auth state is still being determined.

<AuthLoading> is necessary because on first page load, the app has not yet verified whether the user has a valid session (it needs to check the stored session token with the server). Without <AuthLoading>, every signed-in user would see a brief flash of the signed-out UI (the <Unauthenticated> branch) before the session is confirmed and the <Authenticated> branch takes over. <AuthLoading> lets you show a loading indicator during that moment instead.

(a) The three possible values of currentUser:

• undefined (while the query is loading): undefined?._id evaluates to undefined, so isOwner is false. The button is hidden during loading.
• null (user is not signed in): null?._id evaluates to undefined, so isOwner is false. The button is hidden for signed-out users.
• A user document (user is signed in): currentUser._id is compared to item.ownerId, and isOwner is true only if they match.

The optional chaining (?.) handles all three states in one expression.

(b) No. Convex deduplicates identical queries automatically. All 100 instances call useQuery(api.users.currentUser) with the same (empty) arguments, so the client opens only one subscription. Every component receives the same cached value. This is why calling useQuery freely inside components is fine. You pay for the subscription once, no matter how many components ask for it.

export const publishPost = mutation({
  args: {
    postId: v.id("posts"),
  },
  handler: async (ctx, args) => {
    // Step 1: Load the post to find which blog it belongs to
    const post = await ctx.db.get(args.postId);
    if (post === null) {
      throw new ConvexError("Post not found");
    }

    // Step 2: Check that the current user owns the parent blog
    // (assertBlogOwner handles authentication + ownership check)
    await assertBlogOwner(ctx, post.blogId);

    // Step 3: Perform the status change
    await ctx.db.patch(args.postId, { status: "published" });
  },
});

The authorization lookup spans two tables: the document being modified is the post, but the permission check depends on the blog. We have to load the post first to get the blogId, then pass that to the blog ownership guard. That means two database reads, one for the post and one inside the guard for the blog. There is no way around them, and they are cheap.

A JWT (JSON Web Token) is a tamper-proof, signed token that proves a user’s identity. When a user signs in, the server creates a JWT containing the user’s ID and other information, signs it with a cryptographic signature, and hands it to the client. On subsequent requests, the client includes the JWT, and the server verifies the signature to confirm the token is valid and unaltered – without needing to look up session data in a database on every request.

JWTs use asymmetric cryptography (a private/public key pair) rather than a single shared secret for separation of concerns:

• The private key is used to sign (create) tokens. Only the auth server holds this key.
• The public key is used to verify tokens. Any service that needs to validate a JWT can use the public key without ever having the ability to forge new tokens.

This is more secure than a shared secret because if the verification key is exposed (e.g., to a microservice that only needs to validate tokens), an attacker still cannot create fake tokens – they would need the private key for that.

Each OAuth App has a registered callback URL that the provider redirects to after the user authorizes. The dev callback URL points to your development server (e.g., https://dev-slug.convex.site/api/auth/callback/github), while the production callback URL points to your production server (e.g., https://prod-slug.convex.site/api/auth/callback/github).

If you used the same OAuth App for both:

• The callback URL can only point to one deployment. If it points to dev, production sign-ins would redirect to the dev server and fail (or worse, sign the user into the wrong environment). If it points to prod, local development sign-ins would break.
• The JWT signing keys would also need to be shared, meaning a token minted in dev could be valid in production – a security risk.

With separate OAuth Apps, each environment gets its own callback URL, client credentials, and JWT key pair. That keeps the two environments isolated from each other.

The useDraggable hook accepts a disabled option:

const { attributes, listeners, setNodeRef, isDragging } = useDraggable({
  id: item._id,
  disabled: !hasPermission,
});

When disabled is true, dnd-kit stops listening to pointer events, sets aria-disabled="true" for accessibility, and prevents the drag from starting.

To make the disabled state visually clear, update the cursor style so it no longer shows a grab hand for unauthorized users:

<div
  ref={setNodeRef}
  className={cn("text-sm", {
    "cursor-grab active:cursor-grabbing": hasPermission,
  })}
  {...listeners}
  {...attributes}
>
  {item.title}
</div>

Without the cursor change, the UI would still show a grab cursor on hover, which suggests the card is draggable. The drag would not actually start, but the cursor is misleading and the user is left confused. The UI should show which actions are available before the user tries them.