OpenID 2에서 HTML 양식 리디렉션이 사용되는 이유는 무엇입니까?

StackOverflow https://stackoverflow.com/questions/34623

  •  09-06-2019
  •  | 
  •  

문제

단순 리디렉션이 아닌 자동 HTML 게시를 수행하는 이유는 무엇입니까?

이는 개발자가 OpenID가 알려지면 원격 서버에 디렉터리를 게시하는 로그인 양식을 자동으로 생성할 수 있도록 하기 위한 것입니까?

예.

  1. 사용자가 로그인되어 있지 않으며 로그인 페이지를 방문합니다.
  2. 쿠키에서 사용자의 openID를 감지합니다.
  3. 원격 OpenID 서버에 직접 게시되는 양식이 생성됩니다.
  4. 원격 서버는 사용자를 웹사이트로 다시 리디렉션합니다.
  5. 웹사이트는 사용자를 로그인합니다.

이 경우 이점을 볼 수 있습니다.그러나 이는 사용자가 로그아웃할 때 쿠키에 사용자의 openID를 유지한다고 가정합니다.

이 사양을 가장 잘 구현하는 방법에 대한 정보는 거의 찾을 수 없습니다.

공식 사양에서 HTML FORM Redirection을 참조하세요.

http://openid.net/specs/openid-authentication-2_0.html#indirect_comm

이건 짤을 보다가 알게됐어 PHP OpenID 라이브러리 (버전 2.1.1).

// Redirect the user to the OpenID server for authentication.
// Store the token for this authentication so we can verify the
// response.

// For OpenID 1, send a redirect.  For OpenID 2, use a Javascript
// form to send a POST request to the server.
if ($auth_request->shouldSendRedirect()) {
    $redirect_url = $auth_request->redirectURL(getTrustRoot(),
                                               getReturnTo());

    // If the redirect URL can't be built, display an error
    // message.
    if (Auth_OpenID::isFailure($redirect_url)) {
        displayError("Could not redirect to server: " . $redirect_url->message);
    } else {
        // Send redirect.
        header("Location: ".$redirect_url);
    }
} else {
    // Generate form markup and render it.
    $form_id = 'openid_message';
    $form_html = $auth_request->htmlMarkup(getTrustRoot(), getReturnTo(),
                                           false, array('id' => $form_id));

    // Display an error if the form markup couldn't be generated;
    // otherwise, render the HTML.
    if (Auth_OpenID::isFailure($form_html)) {
        displayError("Could not redirect to server: " . $form_html->message);
    } else {
        print $form_html;
    }
}
도움이 되었습니까?

해결책

주된 동기는 Mark Brackett이 말했듯이 리디렉션과 GET을 사용하여 부과된 페이로드 크기 제한이었습니다.일부 구현은 메시지가 특정 크기를 초과할 때만 POST를 사용할 정도로 똑똑합니다. POST 기술에는 확실히 단점이 있기 때문입니다.(그 중 가장 중요한 것은 뒤로 버튼이 작동하지 않는다는 사실입니다.) 인용한 예제 코드와 같은 다른 구현에서는 단순성과 일관성을 추구하고 해당 조건을 생략합니다.

다른 팁

몇 가지 이유를 생각해 볼 수 있습니다.

  • 모호함에 의한 약간의 보안 - GET보다 POST 제출을 조작하는 것이 약간 더 많은 작업입니다.
  • 캐싱 및 다시 제출 규칙은 GET보다 POST에 대해 더 제한적입니다.하지만 이것이 OpenID 사용 사례에 문제가 될지 완전히 확신할 수는 없습니다.
  • 봇은 POST 형식을 따르지 않지만 리디렉션을 따릅니다.이는 서버 로드에 영향을 줄 수 있습니다.
  • 브라우저마다 GET 요청의 최대 길이가 다르지만 POST만큼 큰 것은 없습니다.
  • 일부 브라우저는 다른 도메인으로 리디렉션할 때 경고를 표시합니다.HTTPS가 아닌 URL에 POST를 제출하는 경우에도 경고가 표시됩니다.
  • JavaScript를 끄면 상대적으로 안전한 환경을 누릴 수 있으며 자동으로 다른 도메인으로 리디렉션되지 않습니다.

전송되는 데이터의 양이 일부 주요 브라우저의 쿼리 문자열 길이를 초과하지 않는 한, 이들 중 어떤 것도 POST를 선택해야 하는 절묘한 이유인지는 모르겠습니다.

SAML 웹 브라우저 SSO 프로필에도 동일한 접근 방식이 사용됩니다.HTML Post 리디렉션을 사용하는 주요 동기는 다음과 같습니다.

  • 페이로드 길이는 사실상 무제한입니다.SAML에서 페이로드는 XMLDSig로 서명되고 base64로 인코딩된 XML 문서입니다.URL의 일반적인 1024자 제한보다 큽니다(모든 브라우저뿐만 아니라 방화벽, 역방향 프록시, 로드 밸런서와 같은 중간 네트워크 장치도 지원하는 모범 사례).

  • W3C HTTP 표준에 따르면 GET은 멱등성이 있으므로(동일한 URL GET을 여러 번 실행하면 항상 동일한 응답이 발생해야 함) 결과적으로 POST는 그렇지 않고 URL 대상에 도달해야 하는 반면 캐시될 수 있습니다.OpenID HTML 양식 POST 또는 SAML HTML 양식 POST의 응답은 캐시되어서는 안 됩니다.인증된 세션을 시작하려면 대상에 도달해야 합니다.

URL 쿼리는 항상 변경되고 실제로는 옳기 때문에 HTTP GET 리디렉션을 사용하는 것도 효과가 있다고 주장할 수 있습니다.그러나 이는 W3C 표준의 해결 방법이므로 표준이 아니라 양측이 동의할 때마다 대체 구현이 되어야 합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top