Vulnerable code sample

import os
from flask import Flask, request, redirect
from authlib.integrations.flask_oauth2 import AuthorizationServer

# This code simulates the vulnerable logic of Authlib prior to the fix.
# It is a simplified representation to demonstrate the core flaw.

app = Flask(__name__)
app.secret_key = os.urandom(24)

# In a real application, these methods would interact with a database.
# For this PoC, they are minimal as they are not hit in the vulnerable path.
def query_client(client_id):
    # This function is not called in the vulnerable code path because the
    # response_type check happens before the client is looked up.
    return None

def save_token(token, request):
    pass

# Setup the authorization server
server = AuthorizationServer(
    app,
    query_client=query_client,
    save_token=save_token
)

# This is the vulnerable authorization endpoint.
# The internal logic of `create_authorization_response` in older versions
# would first check for `response_type`. If it was unsupported, it would
# immediately redirect to the user-provided `redirect_uri` without
# validating it against a client's allowed list.
@app.route('/authorize')
def authorize():
    # The vulnerability existed within this method call.
    # An attacker would make a request like:
    # /authorize?response_type=foo&redirect_uri=https://evil.com&client_id=123
    # Because 'foo' is an unsupported response_type, Authlib would raise an
    # error internally and redirect to https://evil.com before ever
    # validating the client_id or the redirect_uri.
    return server.create_authorization_response()

# The following is a simplified manual implementation of the flawed logic
# to make the vulnerability explicit without relying on an old Authlib version.

@app.route('/authorize_vulnerable_logic')
def authorize_vulnerable_logic():
    redirect_uri = request.args.get('redirect_uri')
    response_type = request.args.get('response_type')
    supported_response_types = ['code', 'token'] # Whitelist of supported types

    # FLAW: Check response_type *before* validating the client or redirect_uri.
    if response_type not in supported_response_types:
        # If the response type is unsupported, it constructs an error redirect
        # using the unvalidated `redirect_uri` provided by the user.
        # This creates the open redirect.
        error_url = f"{redirect_uri}?error=unsupported_response_type"
        return redirect(error_url, code=302)

    # In a correct implementation, client and redirect_uri validation
    # would happen here, *before* any other logic.
    # (e.g., check if redirect_uri is in a pre-registered list for the client)
    
    # ... further valid processing would follow
    return "This part is not reached by the exploit.", 200