Deployment And Auth

Purpose and Scope

Deployment and auth are closely related agent-framework primitives: deployment makes an agent or graph reachable as a running service, while auth controls which users, workspaces, providers, and external sessions that service can act on. In the LangChain ecosystem, the deployment quickstart frames cloud deployment around projects that export a graph from langgraph.json and are deployed with langgraph deploy. The Auth Service V2 authenticate endpoint then provides the public contract for starting or checking authentication against a provider, returning either completed credentials or a pending/connection-required state that the deployed agent or client must handle.

Within this repository, the supplied source evidence shows the lower-level auth and session patterns that deployed agents rely on when they connect to model providers and browser-like tools. Provider auth can be OAuth-based, as in the ChatGPT subscription helper, or URL/header-based, as tested by the Ollama integration. Session identity can also be represented independently from credentials: ChatSession is a typed container for a conversation, channel, or message group, and the classic MultiOn tools preserve create, update, and close session entry points through deprecated import shims. Sources: libs/partners/openai/langchain_openai/chatgpt_oauth.py, libs/core/langchain_core/chat_sessions.py, libs/langchain/langchain_classic/tools/multion/create_session.py, libs/langchain/langchain_classic/tools/multion/update_session.py, libs/langchain/langchain_classic/tools/multion/close_session.py, libs/partners/ollama/tests/unit_tests/test_auth.py

Relevant Source Files

• libs/partners/openai/langchain_openai/chatgpt_oauth.py — Implements ChatGPT OAuth helper types, constants, token validation, token storage, refresh behavior, and PKCE/device auth endpoint configuration for _ChatOpenAICodex.
• libs/core/langchain_core/chat_sessions.py — Defines the ChatSession typed dictionary used to represent a conversation, channel, or other message group with messages and function-calling specs.
• libs/langchain/langchain_classic/tools/multion/create_session.py — Keeps the classic MultionCreateSession and CreateSessionSchema import surface available through a deprecated dynamic importer.
• libs/langchain/langchain_classic/tools/multion/update_session.py — Keeps the classic MultionUpdateSession and UpdateSessionSchema import surface available through a deprecated dynamic importer.
• libs/langchain/langchain_classic/tools/multion/close_session.py — Keeps the classic MultionCloseSession and CloseSessionSchema import surface available through a deprecated dynamic importer.
• libs/partners/ollama/tests/unit_tests/test_auth.py — Tests URL parsing for Ollama authentication, including basic-auth header extraction, scheme-less hosts, paths, query strings, and percent-encoded credentials.

Public Auth Contract

The public Auth Service V2 operation is POST /v2/auth/authenticate. Its request body is provider-oriented: provider and scopes are required, while user_id, ls_user_id, agent_id, token_id, and redirect_uri let a caller associate the authentication attempt with a user, LangSmith identity, deployed agent, existing token, or OAuth redirect target. Boolean fields refine the operation: use_agent_builder_public_oauth selects the public OAuth path, force_new asks for a fresh connection, is_default marks a default connection, and check_only lets a caller inspect state without necessarily starting a new flow.

The response is stateful rather than simply credential-shaped. The documented status can be completed, pending, connection_required, or token_expired, and the response may include url, auth_id, token, user_id, and metadata. Application code should therefore treat authentication as a workflow: a deployed agent may be able to proceed immediately, may need to show the user a URL, may need to wait for an external OAuth callback, or may need to request reconnection because a token expired. This maps naturally to agent UI and runtime design, where auth is not just a static environment variable but an interaction state that can pause or resume work.

A minimal request shape looks like this:

{
  "provider": "<provider>",
  "scopes": ["<scope>"],
  "user_id": "<application-user>",
  "ls_user_id": "<langsmith-user>",
  "agent_id": "<deployed-agent>",
  "force_new": false,
  "is_default": true,
  "check_only": false
}

System-to-Code Mapping

The ChatGPT OAuth helper demonstrates why provider-specific auth is kept separate from model invocation. Its module docstring states that it implements OAuth 2.0 Authorization Code Flow with PKCE against OpenAI auth endpoints used by Codex/ChatGPT subscription auth, and that _ChatOpenAICodex consumes a _ChatGPTOAuthTokenProvider rather than managing login directly. The module also warns that this is independent from the standard OpenAI API-key flow used by ChatOpenAI, and it defaults token storage to ~/.langchain/chatgpt-auth.json rather than mutating Codex CLI or VS Code auth state. Sources: libs/partners/openai/langchain_openai/chatgpt_oauth.py

That separation matters for deployment because a cloud agent should not entangle its business logic with browser redirects, refresh-token rotation, local file persistence, or provider policy warnings. The _ChatGPTToken dataclass makes token state explicit with access_token, refresh_token, timezone-aware expires_at, optional account metadata, and hidden repr fields for secret-bearing values. Its validation requires non-empty secrets and a timezone-aware expiration timestamp, which makes refresh and caching safer when a token provider is shared across calls. Sources: libs/partners/openai/langchain_openai/chatgpt_oauth.py

The session side is intentionally smaller but still important. ChatSession is a TypedDict with optional messages and functions, and its docstring defines a chat session as a single conversation, channel, or other group of messages. This gives deployment code and integrations a shared shape for restoring conversation state without forcing every session to carry auth credentials directly. Meanwhile, the MultiOn classic session modules expose CreateSessionSchema, MultionCreateSession, UpdateSessionSchema, MultionUpdateSession, CloseSessionSchema, and MultionCloseSession through dynamic deprecated import lookup, which preserves older tool import paths while moving implementations to langchain_community. Sources: libs/core/langchain_core/chat_sessions.py, libs/langchain/langchain_classic/tools/multion/create_session.py, libs/langchain/langchain_classic/tools/multion/update_session.py, libs/langchain/langchain_classic/tools/multion/close_session.py

Deployment Flow

A deployable application should first expose its agent graph through langgraph.json, then run with a LANGSMITH_API_KEY supplied through a project .env file or inline environment variable. The official deployment quickstart uses langgraph deploy and notes that apps authored with different frameworks deploy the same way once they expose a graph. In practice, auth design should be checked before deploying: decide which credentials are environment-level service secrets, which provider connections are user-specific OAuth flows, and which sessions must be resumed across requests.

At runtime, the deployed service should keep those responsibilities separate. Environment keys such as LANGSMITH_API_KEY identify the deployment or workspace. Provider credentials obtained through an authentication flow should be stored, refreshed, or requested according to that provider’s contract. Conversation state should flow through session abstractions like ChatSession or tool-specific session handles. If a provider returns a connection_required or token_expired status through the Auth Service V2 contract, the agent should surface that state to the user or frontend instead of hiding it behind a generic model failure.

Authentication Implementation Details

The Ollama auth tests show a different, lightweight auth pattern: credentials embedded in a base URL are removed from the cleaned URL and converted into a Basic Authorization header. The tests cover None input, URLs without credentials, full HTTPS URLs, scheme-less host and port strings, localhost, paths, query strings, fragments, percent-encoded usernames and passwords, and credentials with no explicit scheme. This is a useful deployment lesson: connection URLs must be normalized before they are passed to provider clients, and secrets should not remain embedded in URLs that may be logged or reused. Sources: libs/partners/ollama/tests/unit_tests/test_auth.py

The same tests also show that local and containerized deployment ergonomics matter. A value like ollama:11434 is accepted as a scheme-less host and normalized to http://ollama:11434, which is appropriate for Docker networks or local development. When credentials are present, the expected output keeps the host and port but removes the username and password from the URL and places a Base64-encoded user:password value in the Authorization header. That behavior gives application code a cleaner split between endpoint identity and credential transport. Sources: libs/partners/ollama/tests/unit_tests/test_auth.py

Compact Reference

Testing Signals and Next Steps

The strongest executable signal in the supplied source is the Ollama unit test suite, because it enumerates the URL-auth cases that provider integrations must preserve during deployment. The ChatGPT OAuth module provides design signals through invariants, constants, warnings, and token-store choices rather than through this page’s included tests. For implementation work, first decide whether the target provider uses environment keys, URL credentials, OAuth, or a platform-managed Auth Service flow. Then wire session persistence separately from credential acquisition, and make frontend behavior explicit for pending, connection-required, and expired-token states. Sources: libs/partners/openai/langchain_openai/chatgpt_oauth.py, libs/partners/ollama/tests/unit_tests/test_auth.py

Next, read the pages on Sessions and Chat History, Agent Connections API, Frontend Overview, and Message Queues and Streaming UI. Those topics explain how authenticated work is resumed, how provider connections are managed as user-facing resources, and how clients should render long-running or paused agent interactions.