Why are we not using device flow with public clients in MCP?

[mkschreder]

Hi @jlowin. It's a bit puzzling to me why MCP is not using device flow to authorize with the authorization server and get the token. It seems device flow is perfect for MCP. More so than DCR.

What are your thoughts on this?

Device flow without the need to enter device code (just consent) seems to be the most straightforward way to authenticate mcp server to me.

The client should get authorization server url from well-known/oauth-protected-resource. Then client should initiate device flow as a public client (without client secret) with that endpoint, prompt the user to open a url (or do so automatically) and then poll the authorization server for the token. The user then approves the device. Once the client gets the token it just sends that token as bearer to the mcp server with subsequent mcp requests and mcp server then uses the oauth token verifier to verify the token against public keys at the oauth server.

It seems so simple and straightforward - and secure as well. But why are we not doing this? Am I missing something important here? Why do we need DCR or complex proxying of the oauth requests? Why do we need the mcp server itself to be an oauth server?

Here is what the client would be doing to authorize as device:

import os
import time
import json
import base64
import webbrowser

from typing import Tuple
import requests
from authlib.integrations.requests_client import OAuth2Session
from authlib.oauth2.rfc6749.errors import OAuth2Error
from authlib.integrations.base_client.errors import OAuthError


# Set the CA certificates path so that python accepts our custom CA certificate
os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"
os.environ["SSL_CERT_FILE"] = "/etc/ssl/certs/ca-certificates.crt"
# ---------- helpers ----------


def b64url_decode(segment: str) -> bytes:
    padding = "=" * (-len(segment) % 4)
    return base64.urlsafe_b64decode(segment + padding)


def decode_jwt_unverified(jwt_token: str) -> Tuple[dict, dict]:
    header_b64, payload_b64, _sig_b64 = jwt_token.split(".", 2)
    header = json.loads(b64url_decode(header_b64))
    payload = json.loads(b64url_decode(payload_b64))
    return header, payload


def discover(issuer: str) -> dict:
    r = requests.get(
        issuer.rstrip("/") + "/.well-known/openid-configuration", timeout=10
    )
    r.raise_for_status()
    return r.json()

def main():
    base_url = "https://auth.myauthserver.com"
    realm = "myrealm"
    client_id = "myclient"
    client_secret = None  # NOT set for public client
    scope = "openid profile email"

    issuer = f"{base_url.rstrip('/')}/realms/{realm}"
    oidc = discover(issuer)

    device_endpoint = oidc.get("device_authorization_endpoint")
    token_endpoint = oidc.get("token_endpoint")
    if not device_endpoint or not token_endpoint:
        raise SystemExit(
            "Issuer does not advertise device_authorization_endpoint or token_endpoint."
        )

    # Create an Authlib session
    # For public clients, leave client_secret=None; for confidential clients, set it.
    session = OAuth2Session(
        client_id=client_id, client_secret=client_secret, scope=scope
    )

    # 1) Start device authorization
    # Keycloak accepts form-encoded body with client_id (+ client_secret if confidential)
    data = {"client_id": client_id, "scope": scope}
    if client_secret:
        data["client_secret"] = client_secret

    # Use regular requests.post for the initial device authorization request
    # since we don't have a token yet
    dev_resp = requests.post(device_endpoint, data=data, timeout=10)

    if not dev_resp.ok:
        try:
            error_data = dev_resp.json()
            error_msg = error_data.get(
                "error_description", error_data.get("error", "Unknown error")
            )
            raise SystemExit(f"Device authorization failed: {error_msg}")
        except (ValueError, KeyError):
            # If response is not JSON, fall back to raise_for_status
            dev_resp.raise_for_status()

    dev = dev_resp.json()

    user_code = dev["user_code"]
    verification_uri = dev["verification_uri"]
    verification_uri_complete = dev.get("verification_uri_complete")
    device_code = dev["device_code"]
    interval = int(dev.get("interval", 5))

    print("\n=== Device Authorization ===")
    print(f"User Code:        {user_code}")
    print(f"Verification URL: {verification_uri}")
    if verification_uri_complete:
        print(f"(Prefilled)       {verification_uri_complete}")

    # 2) Open the verification page in a browser (user pastes the code if needed)
    try:
        webbrowser.open(verification_uri_complete or verification_uri, new=2)
    except Exception:
        pass
    print("\nIf a browser didn't open, visit the URL above and enter the code.")
    print("Waiting for you to complete authorization...\n")

    # 3) Poll for token using Authlib's fetch_token
    #    Handle the standard device flow errors.
    #    Authlib raises OAuth2Error on non-200 responses from token endpoint.
    while True:
        try:
            token = session.fetch_token(
                url=token_endpoint,
                grant_type="urn:ietf:params:oauth:grant-type:device_code",
                device_code=device_code,
                # For confidential clients, client auth will be sent automatically.
                # For public clients, client_id is already set in the session.
                timeout=10,
            )
            break  # success!
        except (OAuth2Error, OAuthError) as e:
            err = getattr(e, "error", None) or ""
            desc = getattr(e, "description", "") or ""
            if err == "authorization_pending":
                time.sleep(interval)
                continue
            elif err == "slow_down":
                interval += 5
                time.sleep(interval)
                continue
            elif err in ("access_denied", "expired_token", "invalid_grant"):
                raise SystemExit(f"Device flow failed: {err} - {desc}") from e
            else:
                # Unexpected; re-raise with details
                raise

    # 4) Decode & print access token (NO signature verification)
    access_token = token["access_token"]
    header, claims = decode_jwt_unverified(access_token)

    print("=== Access Token (decoded, NOT verified) ===")
    print(
        json.dumps(
            {
                "header": header,
                "claims": claims,
                "token_type": token.get("token_type"),
                "expires_in": token.get("expires_in"),
                "scope": token.get("scope"),
            },
            indent=2,
            sort_keys=True,
            default=str,
        )
    )

    if "id_token" in token:
        _, id_claims = decode_jwt_unverified(token["id_token"])
        print("\n=== ID Token (decoded, NOT verified) ===")
        print(json.dumps(id_claims, indent=2, sort_keys=True))


if __name__ == "__main__":
    main()

[lip3l]

device flow is for input-constrained, human-present devices. mcp clients often run unattended, across many tools/agents, where human interaction and browser consent aren’t acceptable or reliable.
you’d force interactive auth at startup/renewal. that breaks background runs, ci, scheduled agents, and multi-process toolchains that need non-interactive credentials.
polling adds fragility and rate limits. many idps throttle/limit device flow; some enterprise idps disable it entirely or restrict scopes like offline_access.
public-client model weakens binding. without a secret and often without pkce in device flow, you lose strong client binding; enterprises prefer confidential clients, par, mtls, dpop, or signed jwt client auth for auditability and revocation.
audience and scope mismatch. mcp servers act as resource servers; tokens must have the correct aud, scopes, and lifetimes. device flow geared to user login can yield tokens that aren’t ideal for long-lived tool access or service-to-service calls.
token lifecycle management. mcp needs predictable refresh/rotation, revocation, and per-tool isolation. dcr or a broker lets you issue per-tool clients, rotate secrets, enforce scopes, and get clean audit trails.
multi-tenant/marketplace scenarios. a proxy/broker or mcp server-side oauth keeps idp specifics abstracted, supports many providers, normalizes claims, and avoids forcing each client to implement discovery, consent ux, and error handling.
better ux/safety. centralizing auth avoids popping browsers and device codes, reduces phishing surface, ensures consistent policy (mfa, conditional access), and simplifies support.

when device flow can work
good as an opt-in, interactive bootstrap for a single-user desktop client to obtain an initial token/refresh token.
still pair it with proper audience/scopes and a non-interactive renewal plan; many teams prefer pkce + loopback/native app flow instead.

why mcp implementations lean to dcr/proxy/oauth server role
enables confidential clients, par/dpop/mtls, per-tool credentials, policy enforcement, and auditable issuance.
supports non-interactive operation and scale (no polling).
lets the mcp server normalize many idps and present a stable, well-scoped token model to tools.

short answer: device flow is simple and secure for human-attended, input-limited devices, but it doesn’t meet mcp’s non-interactive, multi-tool, enterprise, and audit requirements. it’s reasonable as an optional bootstrap path, not a default.