WebSocket authentication in FastAPI - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is WebSocket authentication in FastAPI?

WebSocket authentication in FastAPI is the process of verifying a user's identity before allowing them to open or maintain a WebSocket connection. It ensures only authorized users can send or receive messages over the WebSocket.

beginner

How can you pass authentication data when establishing a WebSocket connection in FastAPI?

You can pass authentication data via query parameters, headers, or cookies when the client initiates the WebSocket connection. FastAPI can then extract and verify this data before accepting the connection.

intermediate

Why can't you use standard HTTP authentication middleware directly with WebSockets in FastAPI?

Because WebSocket connections upgrade from HTTP and then stay open, the usual HTTP middleware runs only during the initial handshake. After that, WebSocket messages bypass HTTP middleware, so authentication must be handled during or before the connection upgrade.

intermediate

What FastAPI feature helps to authenticate users during WebSocket connection?

FastAPI's dependency injection system can be used with WebSocket endpoints to run authentication logic before accepting the connection. You can create a dependency that verifies tokens or credentials and raises an error if invalid.

beginner

What happens if authentication fails during a WebSocket connection attempt in FastAPI?

If authentication fails, FastAPI can close the WebSocket connection immediately with an error code, preventing unauthorized users from maintaining the connection or exchanging messages.

How do you typically send authentication info when opening a WebSocket in FastAPI?

A In the HTTP response body

B In the WebSocket URL query parameters

C Using WebSocket message headers after connection

D In the HTML meta tags

Authentication info is often sent in the WebSocket URL query parameters because headers cannot be set after the connection is established.

Which FastAPI feature helps run authentication code before accepting a WebSocket connection?

A Event handlers

B Middleware

C Background tasks

D Dependency injection

Dependency injection allows running authentication logic before accepting the WebSocket connection.

What should FastAPI do if a WebSocket authentication check fails?

A Close the connection immediately

B Allow connection but ignore messages

C Send a warning message and keep connection open

D Redirect to login page

The connection should be closed immediately to prevent unauthorized access.

Why can't HTTP middleware fully protect WebSocket connections?

A Because WebSocket messages bypass HTTP middleware after handshake

B Because middleware only works on POST requests

C Because WebSocket uses a different port

D Because middleware is disabled by default

After the initial handshake, WebSocket messages do not pass through HTTP middleware.

Which of these is a common method to authenticate WebSocket clients in FastAPI?

A Sending username in WebSocket messages

B Using cookies after connection

C Token verification in query parameters

D Using IP address filtering only

Tokens passed in query parameters are commonly verified during the connection handshake.

Explain how you would implement authentication for a WebSocket connection in FastAPI.

Think about how FastAPI handles dependencies and connection lifecycle.

Why is WebSocket authentication different from regular HTTP authentication in FastAPI?

Consider how WebSocket connections stay open and how middleware works.

Practice

1. What is the main purpose of WebSocket authentication in FastAPI?

easy

A. To speed up the WebSocket connection process

B. To confirm the user's identity before allowing the WebSocket connection

C. To encrypt the WebSocket messages automatically

D. To log all WebSocket messages for debugging

Solution

1. Step 1: Understand WebSocket authentication role

   Authentication ensures only authorized users can connect to the WebSocket.

2. Step 2: Identify the main goal in FastAPI context

   FastAPI uses authentication to confirm user identity before opening the connection.

3. Final Answer:

   To confirm the user's identity before allowing the WebSocket connection -> Option B

4. Quick Check:

   Authentication = Confirm identity [OK]

Hint: Authentication means confirming user identity before connection [OK]

Common Mistakes:

• Confusing authentication with encryption
• Thinking authentication speeds up connection
• Assuming authentication logs messages

2. Which of the following is the correct way to accept a WebSocket connection with token authentication in FastAPI?

easy

A. await websocket.accept() without checking token

B. Call await websocket.close() before checking token

C. Use await websocket.send_text() before accepting

D. Check token, then call await websocket.accept() if valid

Solution

1. Step 1: Understand WebSocket connection flow

   You must check the token first to decide if connection is allowed.

2. Step 2: Accept connection only if token is valid

   Call await websocket.accept() only after confirming token validity.

3. Final Answer:

   Check token, then call await websocket.accept() if valid -> Option D

4. Quick Check:

   Accept after token check = C [OK]

Hint: Accept connection only after validating token [OK]

Common Mistakes:

• Accepting connection before token check
• Closing connection before checking token
• Sending messages before accepting connection

3. Given this FastAPI WebSocket code snippet, what will happen if the token is invalid?

async def websocket_endpoint(websocket: WebSocket):
    token = websocket.query_params.get('token')
    if token != 'secret123':
        await websocket.close(code=1008)
    else:
        await websocket.accept()
        await websocket.send_text('Welcome!')

medium

A. The connection closes immediately with code 1008

B. The connection accepts and sends 'Welcome!' anyway

C. The server raises a runtime error

D. The connection stays open but no message is sent

Solution

1. Step 1: Check token validation logic

   If token is not 'secret123', the code calls await websocket.close(code=1008).

2. Step 2: Understand WebSocket close behavior

   Calling close immediately ends the connection with the given code.

3. Final Answer:

   The connection closes immediately with code 1008 -> Option A

4. Quick Check:

   Invalid token triggers close(1008) [OK]

Hint: Invalid token triggers immediate close with code 1008 [OK]

Common Mistakes:

• Assuming connection accepts anyway
• Expecting a runtime error
• Thinking connection stays open silently

4. Identify the error in this FastAPI WebSocket authentication code:

async def websocket_endpoint(websocket: WebSocket):
    token = websocket.headers.get('Authorization')
    if token != 'Bearer secret123':
        await websocket.accept()
        await websocket.send_text('Unauthorized')
        await websocket.close()
    else:
        await websocket.accept()
        await websocket.send_text('Welcome')

medium

A. Using headers.get instead of query_params.get

B. Not closing connection on invalid token

C. Accepting connection before sending 'Unauthorized' message

D. Missing await before websocket.close()

Solution

1. Step 1: Analyze connection flow on invalid token

   The code calls await websocket.accept() before sending 'Unauthorized' and closing.

2. Step 2: Understand best practice for unauthorized access

   It is better to close connection immediately without accepting it to avoid opening unauthorized connection.

3. Final Answer:

   Accepting connection before sending 'Unauthorized' message -> Option C

4. Quick Check:

   Unauthorized should close without accept [OK]

Hint: Do not accept connection before rejecting unauthorized users [OK]

Common Mistakes:

• Accepting connection before rejecting
• Ignoring connection close on invalid token
• Confusing headers and query parameters

5. You want to authenticate WebSocket connections in FastAPI using a token passed as a query parameter. Which approach correctly handles authentication and rejects unauthorized users cleanly?

hard

A. Check token from query params; if invalid, call await websocket.close(1008) before accept; else accept connection

B. Accept connection first, then check token; if invalid, send 'Unauthorized' message and close

C. Ignore token and accept all connections; handle authorization in message handlers

D. Check token in headers only; ignore query parameters

Solution

1. Step 1: Understand token location and validation

   Token is passed as query parameter, so check websocket.query_params for token.

2. Step 2: Handle unauthorized users before accepting connection

   If token is invalid, close connection immediately with code 1008 to reject cleanly.

3. Step 3: Accept connection only if token is valid

   Only call await websocket.accept() after confirming token validity.

4. Final Answer:

   Check token from query params; if invalid, call await websocket.close(1008) before accept; else accept connection -> Option A

5. Quick Check:

   Reject before accept with close(1008) = A [OK]

Hint: Reject unauthorized before accept using close(1008) [OK]

Common Mistakes:

• Accepting connection before token check
• Ignoring query parameters for token
• Handling authorization after connection open