사용자가 “로그인”을 클릭하면 공급자 페이지에 도달한 뒤 Rails로 돌아옵니다. 다음 단계는 Rails 서버에서 새 연결을 시작하기 때문에 여전히 실패할 수 있습니다.

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

브라우저는 자체 네트워크 설정으로 인가 리디렉션을 따릅니다. Rails는 설치된 OmniAuth 전략이 선택한 HTTP 클라이언트로 백채널 토큰 교환을 수행합니다. 기업 프록시 뒤에서 실행되는 워커는 공급자로 보내는 요청에 이 경로가 필요합니다.

OAuth 1.0에도 사용자가 접근을 승인하기 전에 서버 측 요청 토큰 단계가 있습니다. OAuth 2.0의 인가 코드 흐름에는 콜백 이후 자체적인 토큰 교환이 있습니다. 정확한 순서는 전략에 따라 다르지만, 브라우저와 애플리케이션 서버는 여전히 서로 다른 출발점입니다.

클라이언트 구성 찾기

전략을 따라가 그 토큰과 공급자 API 요청을 보내는 HTTP 클라이언트까지 확인하세요. 해당 클라이언트의 문서화된 프록시 옵션을 사용하세요. 일부 전략은 클라이언트 옵션을 OAuth 라이브러리에 넘기고, 다른 전략은 그 아래에 HTTP 연결을 구성합니다. 한 전략이 받아들이는 옵션이 자동으로 OmniAuth의 공통 옵션이 되지는 않습니다.

공급자의 인가, 토큰, 콜백 URL은 실제 서비스를 가리키도록 두세요. 아웃바운드 프록시는 공급자에 도달하기 위한 전송 설정이며, 콜백 주소를 대신하거나 OAuth 요청 매개변수에 추가하는 필드가 아닙니다.

로그인을 추적할 때 마지막으로 완료된 단계를 표시하세요. 공급자 로그인 페이지가 표시되었다면 브라우저 경로가 동작했다는 뜻입니다. Rails가 콜백을 받았다면 브라우저가 돌아왔다는 뜻입니다. 그다음 토큰 요청이 바로 Rails 프로세스에서 나오는 프록시 연결, 챌린지, 공급자 응답을 점검할 지점입니다.

관련 글