Tracing an OmniAuth Login Through a Proxy

A user clicks “Sign in,” reaches the provider's page and returns to Rails. The next step can still fail because it starts a new connection from the Rails server.

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

The browser follows the authorization redirect using its own network configuration. Rails performs the backchannel token exchange using the HTTP client selected by the installed OmniAuth strategy. A worker running behind a corporate proxy needs that route on its provider requests.

OAuth 1.0 also has a server-side request-token step before the user authorizes access. OAuth 2.0's authorization-code flow has its own token exchange after the callback. The exact sequence depends on the strategy, but the browser and application server remain distinct starting points.

Locate the client's configuration

Follow the strategy to the HTTP client that sends its token and provider API requests. Use that client's documented proxy option. Some strategies pass client options to an OAuth library; others configure an HTTP connection underneath it. An option accepted by one strategy is not automatically a shared OmniAuth option.

Keep the provider's authorization, token and callback URLs describing their actual services. The outbound proxy is a transport setting used to reach the provider, not a replacement callback address or a field to add to the OAuth request parameters.

When tracing a sign-in, label the last completed step. A rendered provider login page establishes that the browser's route worked. A callback received by Rails establishes that the browser returned. The subsequent token request is the point to inspect for a proxy connection, challenge or provider response from the Rails process.