Oauthlib: 클라이언트 웹 응용 프로그램은 더 이상 client_id를 보내지 않습니다.

내 첫 번째 생각은 기본적으로 WebApplicationClient 생성자에 설정된 self.client_id 사용하도록 prepare_request_body 의 변경 사항을 되돌리는 것입니다.
그런 다음 &client_id=xx 를 prepare_request_body 출력에 추가하도록 인라인 문서를 적절히 변경해야 합니다.

마지막으로 원래 수정 사항을 대체하기 위해 인수에서 client_id 를 제거하고 prepare_request_body 와 같이 include_client=True/False prepare_request_body 새 인수를 추가하여 client_id 추가하는 것이 좋습니다. client_secret 를 본문에 포함하거나 둘 다 포함하지 마십시오.

생각?

포케 @Diaoul @skion @thedrow

이건 어떤가요:

args에서 client_id를 제거하고 include_client=True/False와 같은 새 인수를 prepare_request_body에 추가하여 본문에 client_id와 client_secret을 모두 추가하거나 둘 다 포함하지 않는 것이 좋습니다.

감사 해요

실제로 내 테스트 중 하나에서 이와 동일한 문제를 발생시켰지만 https://github.com/requests/requests-oauthlib/issues/330 에서 requests/oauthlib에 대해 제출했습니다.

나는 문제가 실제로 requests_oauthlib의 잘못이라고 생각합니다. 그들의 문서 - 실제로 페이지를 로드할 때 전체 문서의 첫 번째 예 - OAuth2Session 생성자에서 client_id 지정을 지원합니다. 200행의 논리는 kwargs에서 client_id 가져오지만 이미 구성된 WebApplicationClient 인스턴스에서 가져오기 위한 폴백이 없습니다.

@jvanasco , 현재 문제 #585는 requests-oauthlib 단독으로 또는 oauthlib의 PR #505를 되돌려서 수정할 수 있습니다. 그러나 어떤 솔루션도 https://github.com/oauthlib/oauthlib/pull/505#issuecomment -351221107에서 @skion 이 언급한 동작을 수정할 수 없습니다.

사양에 따르면 client_id 매개변수는 인증되지 않은 클라이언트에 대해 전송되어야 하지만 기밀 클라이언트에 대한 토큰 요청 본문에서는 전송되지 않는 것이 좋습니다. 이 경우 클라이언트를 인증하는 기본 메커니즘이 HTTP 기본 인증을 사용하기 때문입니다. 그러나 WebApplication 클래스는 항상 이를 포함하며(일부 서버가 중단됨) 이를 제거하는 메커니즘을 제공하지 않습니다.

Oauthlib는 requests-oauthlib가 문제를 해결할 수 있는 우아하고 간단한 방법을 제공해야 합니다. 이 토론에서 해결책을 찾을 수 있다면 정말 좋을 것입니다. 그것은 거대한 차단기이기 때문입니다.

수겠습니까 client_id=False 에서 prepare_request_body() CLIENT_ID가 아님을 표시하기 위해 도움이 확인할 수 있습니다? 그렇다고 해도 126행 근처에서 이 추악함을 초래할 것입니다.

client_id = None if client_id=False else self.client_id

아, 알겠습니다.

client_id를 보내야 하는 경우와 그렇지 않은 경우에 대한 기존 단위 테스트가 있습니까? 그렇지 않은 경우 목록을 생성하는 데 사용할 수 있는 목록이 있는 사람이 있습니까? 지금 당장 내 작업 중 일부를 차단하고 있기 때문에 이 문제와 요청 oauthlib를 수정하는 데 도움이 되었으면 합니다.

@JonathanHuot

args에서 client_id를 제거하고 include_client=True/False와 같은 새 인수를 prepare_request_body에 추가하여 본문에 client_id와 client_secret을 모두 추가하거나 둘 다 포함하지 않는 것이 좋습니다.

다시 읽어보니 당신의 제안이 정말 마음에 듭니다. 함수가 이미 **kwargs 취하기 때문에 우리는 아마도 깨지지 않는 방식으로 그것을 할 수 있을 것입니다.

한 가지 참고 사항:

본문에 client_id와 client_secret을 모두 추가하려면

이것은 공개 클라이언트 IIUC에 관한 것이므로 client_secret 가 관련되어 있다고 생각하지 않습니다. client_id 이 본문에 추가되는 것뿐입니까? 이 경우 새 매개변수의 이름을 include_client_id=True/False 바꾸는 것도 고려할 것입니다.

이 경우 새 매개변수의 이름을 include_client_id=True/False로 바꾸는 것도 고려할 것입니다.

물론 ! client_secret 그것이 존재하지 않기 때문에 관여하지 않습니다 WebApplicationClient .

@jvanasco , PR을 하고 싶다면 다음과 같이 변경해야 한다고 생각합니다.
1) https://github.com/oauthlib/oauthlib/pull/505 되돌리기
2) 변경 서명 prepare_request_body() 제거합니다 client_id 추가합니다 include_client_id=True/False ( True (기본값) :이 추가 self.client_id )

그런 다음 requests-oauthlib는 https://github.com/requests/requests-oauthlib/blob/master/requests_oauthlib/oauth2_session.py#L196-L211에서 다음 중 하나를 선택할 수 있습니다.
A) 본문에 client_id 만 포함

self._client.prepare_request_body(..)

B) client_id 및 client_secret 를 auth 포함하고 본문에는 포함하지 않음(RFC 기본 솔루션)

self._client.prepare_request_body(include_client_id=False, ..)
auth = requests.auth.HTTPBasicAuth(client_id, client_secret)

C) 본문에 client_id 및 client_secret (RFC 대체 솔루션)

self._client.prepare_request_body(client_secret=client_secret, ..)

오늘 두 프로젝트에 대한 PR을 생성하겠습니다.

OAuthlib에 대한 PR 및 테스트를 거의 완료했습니다. 질문이 있습니다만...

client_id 여전히 kwarg로 허용되어야 합니까? 이는 부분적으로 하위 호환성을 위한 것이지만 극단적인 경우에도 마찬가지입니다. 이 방법이 다소 잘못되었기 때문에 의도한 대로 작동하게 만들거나( prepare_request_body 에서 self.client_id를 재정의하도록 허용하는 것과 같이) 잘못된 사용에 대해 예외를 발생시키는(예를 들어 client_id 가 제공되었지만 self.client_id 와 일치하지 않으면 오류가 발생합니다.

client_id 를 다른 값으로 재정의하려는 방법을 알지 못하므로 다를 경우 예외를 발생시키는 데 투표할 것입니다.

우리는 또한, 로그인해야 DeprecationWarning 의 경우 client_id kwarg 모든 제공되었다?

PR #593이 제출되었습니다. client_id 가 제출되면 DeprecationWarning 을 발생시키고 self.client_id 와 다르면 ValueError 를 발생시킵니다. @JonathanHuot가 자세히 설명한 세 가지 시나리오를 준수하는지 확인하는 새로운 테스트도 있습니다.

몇 가지 테스트를 작성할 때 requests-oauthlib PR 후보에 대한 첫 번째 문제가 발생했습니다.

그것은 항상 호출 prepare_request_body 가진 username=username, password=password . 이것은 잘못된 것 같습니다. 여기 누군가가 RFC에 더 익숙하고 다음에 대한 답을 알고 있기를 바랍니다.

1. username + password 가 request.body 의 매개변수여야 합니까?
2. username + password 가 HTTP 기본 인증 헤더에 나타나면 요청 본문에 중복되어야 합니까?
3. username + password 본문 매개변수와 클라이언트 세부정보가 포함된 HTTPBasicAuth 헤더를 모두 가질 수 있습니까?

실행해 주셔서 감사합니다.

1. username 및 password 는 항상 요청 본문에 에만 사용해야 합니다. 다른 권한 부여(암시적, 코드, 클라이언트 자격 증명)에 사용해서는 안 됩니다.
2. HTTP 기본 인증은 클라이언트 자격 증명에 대해 선택 사항입니다(기밀 클라이언트에 권장(예: client_secret )). 사용자 자격 증명은 HTTP 기본 인증이 아니 어야 합니다.
3. 예

감사 해요. 두 가지만 명확히 하고, 제가 다섯 살인 것처럼 자유롭게 이야기해 주십시오. 이 테스트와 테스트를 올바르게 수행하고 싶습니다.

1. 사용자 이름과 비밀번호는 이를 필요로 하는 특정 유형의 권한 부여에만 사용됩니다. 사용되는 경우 요청 본문에만 존재할 수 있습니다.

명시적으로 지정되지 않는 한 존재해서는 안 됩니다. 맞습니까?

1. Http 기본 인증이 클라이언트 자격 증명만을 위한 것이라면 기존 requests-oauthlib에는 사용자 이름 및 암호 콤보에서 기본 인증을 생성하는 블록이 없어야 합니다.

이 작은 세부 사항에 대해 장황하고 집착하는 저를 용서해 주십시오. j가 올바른 동작을 취하고 또 다른 회귀가 발생하지 않도록 테스트를 작성할 수 있는지 확인하고 싶습니다.

@jvanasco , OAuth2 RFC에 대해 말할 수 있지만 requests-oauthlib 와 flask-oauthlib 어떻게 맞는지 잘 모르겠습니다.

1. 예

옳은.

1. 예, AFAIU에는 https://github.com/requests/requests-oauthlib/blob/master/requests_oauthlib/oauth2_session.py#L207 -L211 블록이 없어야 합니다.

내가 이해하지만 현장의 현실과 대조하는 것이 좋을 것입니다. 즉, requests-oauthlib 및 다른 공개 공급자 경험. 여러 요청-oauthlib 토론 https://github.com/requests/requests-oauthlib/issues/218 , https://github.com/requests/requests-oauthlib/issues/211 , https://github.com/requests /requests-oauthlib/issues/264 , 이미 발생했습니다.

나는 그들이 client password 와 client secret 사이에 혼동이 있었다고 생각합니다. 이는 실제로 정확히 같은 것에 대한 두 가지 표현입니다.
https://github.com/requests/requests-oauthlib/pull/206 뒤에 있는 근거를 따른다면 PR의 내용은 HTTPAuth(username, password) 추가하는 것과 같을 수는 없지만 HTTPAuth(client_id, client_secret 여야 합니다. (클라이언트의 비밀번호).

requests-oauthlib의 토론에 참여한 @Lukasa , @chaosct , @ibuchanan 을 찌르십시오.

엄청난! 정말 고마워. 나는 그것이 무슨 일이 일어나고 있는지 생각했지만 확인하고 싶었습니다.

이제 요청 내용을 구성하는 방법을 알 것 같습니다. 주요 요청 프로젝트에 대한 커밋이 몇 개 있으므로 유지 관리자가 PR 및 기능에서 무엇을 보고 싶어하는지 알고 있습니다.

1. 사용자 이름과 비밀번호는 이를 필요로 하는 특정 유형의 권한 부여에만 사용됩니다. 사용되는 경우 요청 본문에만 존재할 수 있습니다.

예, 첫 번째 부분은 특정 유형의 보조금에만 필요합니다. 그러나 요청 본문에 보내는 것에 대한 두 번째 부분에서 사양은 다음과 같이 말합니다.

요청 본문에 클라이언트 자격 증명 포함
두 매개변수를 사용하는 것은 권장되지 않습니다.
직접 활용할 수 없는 클라이언트로 제한되어야 합니다(SHOULD).
HTTP 기본 인증 체계...

그러나 서버의 경우 다음과 같이 읽습니다.

인증 서버는 다음을 지원할 수 있습니다.
요청 본문의 클라이언트 자격 증명...

준수 클라이언트는 요청 본문에 자격 증명을 보내지 않습니다.
그러나 부분적으로 구현된 일부 서버의 경우 요청 본문에서만 수락합니다.
내가 올바르게 기억한다면 내 PR은 인증 헤더를 추가하여이 혼란을 해결했습니다.
그래서 클라이언트는 둘 다 보냅니다.

나는 @JonathanHuot 가 두 번째 요점에 대해 정확하다고 믿습니다.

@ibuchanan 님 , 귀하가 언급한 인용문은 client credentials 용어를 사용하고 있습니다. 클라이언트와 리소스 소유자(실제 사용자)가 섞이지 않도록 매우 주의해야 합니다.

역할은 여기 rfc6749#1.1에 명확하게 설명되어 있습니다.
이 client credentials 는 client_id 및 client_secret 참조하고 리소스 소유자는 username 및 password 합니다. 그것들은 교환할 수 없습니다.

따라서 해당 역할로 RFC를 읽는 것은 준수 클라이언트가 HTTP Basic에서 클라이언트 자격 증명 ( client_id , client_secret )을 보내야 하고 사용자 자격 증명 ( username , password ) 요청 본문의 (여기서 대안을 읽지 마십시오); rfc6749#4.3.2를 참조하십시오.

client_id가 요청에 있는 경우 일부 서버는 요청을 거부합니다(400).
신체. 기본값은 사양에서 권장하는 것이어야 한다고 생각합니다.

확인. oauthlib 대한 현재 PR이 위의 문제를 충족한다고 생각합니다. include_client_id 플래그는 client_id 전송 여부를 명시적으로 허용합니다.

requests_oauthlib 에서 이것이 내가 생각하는 것입니다.

1. username 및 password 는 본문에만 나타납니다(HTTP 기본이 아님). 그 행동이 비 호환 서버 통합을 위해 필요한 경우, 구현은 제출할 수 있습니다 auth 또는 headers 에 인수 fetch_token() .

2. client_id 를 올바른 위치에 제공하는 것은 약간 성가신 일이지만 논리와 사용 사례가 다운된 것 같습니다. 이것은 확실히 약간의 검토가 필요합니다.

내가 @JonathanHuot 및 @ibuchanan 위해 가지고 질문 :

oauthlib 의 OAuth2 Client 및 requests_oauthlib 의 OAuth2Session 는 client_secret 유지하지 않으며 반복적으로 호출해야 합니다. 이것은 OAuth1의 경우가 아니며 이것이 #370의 실제 문제라고 생각합니다. RFC는 이에 대한 필요성을 언급하지 않았으며 나는 어떤 기록도 찾을 수 없었습니다.

나에게 client_secret 를 저장하여 클라이언트를 확장하고 fetch_token 및 request client_secret 전달에 대한 OAuth2Session 의존을 더 이상 사용하지 않는 것이 합리적입니다 request 현재 클라이언트 자체에서 사용하는 것에 찬성합니다. (이는 https://github.com/requests/requests-oauthlib/issues/264에 보고된 다른 불일치도 해결합니다.)

username/password 및 client_id/client_secret에 대한 테스트 변수를 표준화하기 위해 oauthlib(#593)의 PR을 약간 변경했습니다. 앞으로 이 둘 사이에 혼동을 일으키는 실수를 방지해야 한다고 생각합니다.

requests-oauthlib에 대해 제안된 변경 사항: https://github.com/requests/requests-oauthlib/compare/master...jvanasco :fix-oauthlib_client_id

이것은 좀 더 과감합니다. 코드와 테스트를 보면 라이브러리가 해서는 안 되는 모든 종류의 일을 작동시키려는 것처럼 보이기 때문입니다.

수정 사항은 다음과 같은 몇 가지 작업을 수행합니다.

1. username 및 password 은 LegacyApplicationClient 인스턴스에 대해서만 발생합니다. 필요한 유일한 종류여야 하기 때문입니다(맞습니까?). 검사 아래에 사용자 이름/암호를 kwargs 사전에 병합하는 섹션이 있습니다. 테스트 결과 다른 클라이언트가 이 정보를 전달할 수 있음을 시사하기 때문에 현재는 내어쓰기되어 있습니다.

2. client_id/auth 헤더를 처리하는 논리는 기본적으로 올바른 유형의 인증이 올바른 위치에서 발생하도록 다시 작성되었습니다. 사용자가 다른 방법으로 자격 증명을 강제 적용하려는 경우 여전히 가능합니다.

3. 질문: client_secret 가 통과되지 않는 상황이 있습니까? 아무 생각이 안 나지만 oAuth 흐름이 많이 있습니다.

그래서 requests-oauthlib 버전에서:

| include_client_id | auth | 행동 |
| ------------------- | --------------- | -------- |
| 없음(기본값) | 없음(기본값) | client_id 사용하여 Auth 개체를 만듭니다. 본문에 client_id를 보내지 마십시오. 이것은 RFC에서 권장하기 때문에 기본 동작입니다. |
| 없음(기본값) | 선물 | Auth 개체를 사용합니다. include_client_id=False oauthlib의 prepare_request_body 호출 |
| 거짓 | 선물 | Auth 개체를 사용합니다. include_client_id=False oauthlib의 prepare_request_body 호출 |
| 사실 | 선물 | Auth 개체를 사용합니다. include_client_id=True oauthlib의 prepare_request_body 호출 |
| 사실 | 없음(기본값) | client_id 사용하여 Auth 개체를 만듭니다. include_client_id=True oauthlib의 prepare_request_body 호출 |
| 거짓 | 없음(기본값) | client_id 사용하여 Auth 개체를 만듭니다. include_client_id=False oauthlib의 prepare_request_body 호출 |

또는 달리 명시:

• 인증 객체 생성
  
  
  
  • 본문에 클라이언트 ID를 보내지 마십시오.
  
  
  • (include_client_id=없음, 인증=없음)
  
  
  • (include_client_id=거짓, 인증=없음)
  
  
  • 본문에 클라이언트 ID를 보냅니다.
  
  
  • (include_client_id=참, 인증=없음)
  
  
• 명시적 인증 객체 사용
  
  
  
  • 본문에 client_id를 보내지 마십시오.
  
  
  • (include_client_id=없음, 인증=authObject)
  
  
  • (include_client_id=거짓, 인증=authObject)
  
  
  • 본문에 client_id를 보냅니다.
  
  
  • (include_client_id=참, 인증=authObject)
  
  

@jvanasco : oauthlib 및 requests-oauthlib 측에서 매우 좋아 보입니다.

귀하의 3. 질문에 대해:

client_secret 없이 공개 클라이언트를 가질 수 있습니다(또는 RFC의 관점에서 비어 있음). 따라서 파이썬 API는 "비밀 없음"을 지원해야 합니다.

실제 사용 사례는 종종 인증 코드를 사용하는 것을 선호하지만 비밀을 안전하게 유지하는 것에 대한 보안을 보장할 수 없으므로 client_secret 없이 client_id 를 수락하거나 client_secret (또는 RFC와 동일한 빈 client_secret ); 또는 다른 PKCE RFC도 사용할 수 있습니다(https://oauth.net/2/pkce/ 참조). 그러나 후자는 아직 oauthlib 측에서 구현되지 않았습니다.

감사 해요. client_id 없이 client_secret client_id 를 제출할 수 있도록 몇 가지 테스트 사례를 추가하겠습니다. 너무 많은 질문을 해서 죄송합니다. 이 사양의 가능한 올바른 구현이 너무 많습니다(그리고 작동해야 하는 더 깨진 구현도 있습니다).

@JonathanHuot 기존 구현은 client_secret 대한 빈 문자열 전송을 지원하지 않습니다. 이 논리에서 제거되었습니다. https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth2/rfc6749/parameters.py#L90 -L125 -- 특히 122행

이를 지원하는 것은 해당 루틴 직후에 다음과 같은 것을 추가할 수 있습니다.

if ('client_secret' in kwargs) and ('client_secret' not in params):
    if kwargs['client_secret'] == '':
        params.append((unicode_type('client_secret'), kwargs['client_secret']))

비밀이 빈 문자열인 경우 client_secret 에 대한 빈 문자열을 보내지만 값이 None 이면 client_secret 보내지 않습니다.

RFC가 두 가지 변형 중 하나를 지원한다면... 하나의 변형만 지원하는 많은 깨진 구현이 있을 가능성이 높기 때문에 이것을 지원할 가치가 있다고 생각합니다.

이 원래 문제는 oauthlib에서 수정되었습니다. 그러나 이 동작은 https://github.com/requests/requests-oauthlib/pull/331 이 수정될 때까지 여전히 존재합니다.