Oauthlib: 오류 응답 시 잘못된 HTTP 상태

사양에는 401이 잘못된 클라이언트 오류와 함께 사용될 수 있으며 인증 헤더 필드를 통해 인증이 완료될 때 사용해야 한다고 언급되어 있습니다. oauthlib는 현재 사양에서 요구하는 대로 'WWW-Authenticate' 헤더 필드가 응답에 포함되어야 한다고 제안하지 않습니다. 이 오류에 대해 401을 유지하는 것은 괜찮다고 생각하지만 예외에 헤더 제안을 추가해야 합니다.

다른 사양에 관해서는 사양에 401이 사용될 수 있다고 명시적으로 명시되어 있지 않으므로 400으로 변경하는 것을 고려해야 합니다. 그러나 유효하지 않은 승인과 특히 승인되지 않은 클라이언트 오류 모두에서 401이 더 적절해 보입니다.

@asteinlein , @lepture , @masci 생각?

@ib-lundgren 안녕하세요-이 바로 이 문제를 우연히 발견하여 차임하고 싶습니다. 사양을 읽고 다른 답변을 살펴보니 IMO a 400이 정답입니다.

먼저 사양:

인증 서버가 HTTP 400(잘못된 요청)으로 응답합니다.
상태 코드(달리 지정하지 않는 한) 및 다음을 포함합니다.
응답이 있는 매개변수:

400 요구 사항에는 MUST가 없지만 MAY도 없습니다.

둘째, 내가 이것을 우연히 발견한 이유는 내 클라이언트의 Sun JDK에 있는 일종의 버그를 통해서였습니다(여기 참조: http://stackoverflow.com/a/7524681/1137254 ).

기본적으로 내 클라이언트의 HTTP 스택은 401에 대해 일찍 연결을 닫지만 위의 OAuth 스택(google-http-oauth-client)은 계속해서 결과를 읽고 구문 분석하려고 시도합니다. 나는 이것이 401 (업데이트 : 실제로 '스트리밍'모드와 관련이 있음)에 대한 정의 및 기대에 따라 OpenJDK에 작성되었다고 생각합니다. IMO OpenJDK도 잘못되었으며 /token 끝점 요청 중에 "invalid_client" 401이 발생하면 이와 동일한 문제가 발생할 것이라고 생각합니다.

여기에 올바른 오류 코드인 400에 대한 또 다른 투표를 추가합니다. 모바일 앱에서 oauth2 인증을 위해 django-oauth2-provider를 사용했는데 이 경우 400을 반환했습니다. 최신 Django 버전으로 업그레이드하기 위해 django-oauth-toolkit(oauthlib 사용)으로 전환할 때 모바일 앱이 올바르게 작동하도록 하기 위해 대신 400을 반환하도록 토큰 요청 보기를 해킹해야 했습니다.

다음은 토큰을 요청할 때 400이 잘못된 인증 자격 증명에 대한 의도된 응답이며 그 이유를 명시한 사양 작성자 중 한 명입니다. https://www.ietf.org/mail-archive/web/oauth/current/msg02127 .html

그리고 이러한 상황에서 401을 사용하여 oauthlib에 대처하는 데 문제가 있는 프로젝트의 또 다른 예가 있습니다.

400에 +1

400에 투표하세요

이 오래된 스레드를 되살리고 위에서 제안한 변경 사항으로 PR을 시작합니다.

이에 대해 진행하기 전에 과거에 있었던 논의를 요약하고 싶습니다.

• OAuth2.0 RFC6749 작업 그룹 은 WWW-Authenticate 를 설정해야 하기 때문에 오류 HTTP 상태에 대해 401 대신 400을 채택하기로 결정했으며 모든 오류 응답에서 항상 가능한 것은 아닙니다.
• @asteinlein 은 oauthlib의 오류를 400에서 401로 변경하기 위해 https://github.com/oauthlib/oauthlib/pull/247 에서 PR을 제안했습니다. _일부 클라이언트는 인증과 관련된 API 호출에 대해 401을 예상하는 것으로 보이기 때문입니다_. 그것이 사실이어야 했지만 우리는 어떤 클라이언트가 망가졌는지 모릅니다.
• 타사 라이브러리에 여러 버그 팝업 https://github.com/oauthjs/angular-oauth2/issues/31 https://github.com/oauthjs/angular-oauth2/issues/32#issuecomment -88888755 https://github .com/oauthjs/angular-oauth2/issues/36 . 이제 문제가 모두 종료되었습니다.
• 현재 스레드와 RFC6749#5.2 의 전반적인 합의는 oauthlib의 모든 401 가 400 여야 한다는 것입니다. 그러나 401 두 가지 경우가 있습니다.

1. invalid_client , HTTP 인증이 사용되는 경우 $ 401 여야 하고, 그렇지 않으면 401 수 있습니다.
2. invalid_token , 여기서 401 여야 합니다.

어쨌든 401 가 사용되면 WWW-Authenticate 를 설정 해야 합니다( RFC2616 ).

기타 OAuth2.0 구현

가장 일반적인 OAuth2.0 구현에 대한 간략한 개요는 전반적인 합의와 유사합니다.

• Google은 400 so-question / so-question 을 반환합니다.
• Salesforce에서 400 salesforce-forum 을 반환합니다.
• Azur는 $ WWW-Authenticate azur-docs 와 함께 $ 401 를 반환합니다.
• AWS는 400 aws-cognito-docs를 반환합니다. 그들은 HTTP 인증이 사용될 때 RFC의 " MUST "를 401 로 깨뜨렸습니다.

결론

RFC에 맞춰야 하지만 구현을 중단하지 않으려면 이러한 변경 사항을 2.xx 버전에 포함하지 않고 3.xx까지 기다려야 합니다.

부담없이 끼어주세요.

저로 하여금 PR #247을 푸시하게 한 이유/클라이언트를 기억할 수 없지만, 이것을 되돌리는 이유를 보고 이해합니다. @JonathanHuot 의 멋진 연구에 감사드리며 3.x에서 이 작업을 수행하는 것이 가장 좋은 방법인 것 같습니다.

#561 / oauthlib>= 3.0.0에서 수정됨

위에서 언급한 이 RFC에 따르면 잘못된 클라이언트도 상태 400을 반환해야 하지만 패키지에서는 여전히 401입니다.

안녕하세요 @esfandiaryfard , RFC의 정확한 텍스트를 가리킬 수 있습니까? 감사 해요!