Oauthlib: Client_secret 및 code_verifier(PKCE)는 안전하게 전송되어야 합니다.

안녕하세요 @polamayster , 당신이 완전히 옳았습니다.

구현 방법을 지정하는 RFC 섹션을 추가하고 있습니다.

OAuth2.0 RFC 섹션:

https://tools.ietf.org/html/rfc6749#section -2.3.1

2.3.1.  Client Password
   Clients in possession of a client password
   MAY use the HTTP Basic authentication scheme (..) 

   Alternatively, the authorization server
   MAY support including the client credentials in the request-body (..)

   The parameters can only be transmitted in the request-body and
   MUST NOT be included in the request URI.

PKCE RFC 섹션:

https://tools.ietf.org/html/rfc7636#section -4.5

4.5.  Client Sends the Authorization Code and the Code Verifier to the
      Token Endpoint
    In addition to the parameters defined in the OAuth 2.0 Access
    Token Request (Section 4.1.3 of [RFC6749]), it sends the following parameter:

   code_verifier
      REQUIRED.  Code verifier

https://tools.ietf.org/html/rfc6749#section -4.1.3

4.1.3.  Access Token Request

   The client makes a request to the token endpoint by sending the
   following parameters (..) in the HTTP request entity-body:

그래서 나는 그 문제의 타당성에 대해 의심의 여지가 없습니다. 어떤 PR도 환영합니다!

나는 이것을 받아들이는 데 관심이 있을 것이다. 곧 풀 리퀘스트를 제출할 예정입니다.

이 동작은 자격 증명이 필요한 요청이나 일반적인 요청에 대해서만 시행되어야 합니까?

내 이해에 oauthlib.common.Request 클래스에는 __getattr__ 메서드와 _params 사전(쿼리 문자열 및 본문 매개변수에서 업데이트됨) 및 client_secret 에 액세스/가져오려는 모든 요청 이 있습니다 client_secret 또는 code_verifier 는 본문 및/또는 헤더에서만 조회해야 합니다(민감한 데이터 조회를 위해 별도의 속성을 갖는 것이 합리적일 수 있음).

알겠습니다. 오늘 홍보를 제출하겠습니다.

2019년 4월 20일 토요일 오후 12:38 Bohdan < [email protected] 작성:

내 이해에 oauthlib.common.Request 클래스에는 __getattr__이 있습니다.
메서드 및 _params 사전(쿼리 문자열 및 본문에서 업데이트됨
매개 변수) 및하려고 모든 요청 액세스 / GET client_secret 또는
code_verifier는 본문 및/또는 헤더에서만 조회해야 합니다(아마도
민감한 데이터 조회를 위한 별도의 속성이 적합함)

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485157051 ,
또는 스레드를 음소거
https://github.com/notifications/unsubscribe-auth/ABKEVQNFJUFGDB5X24JBOJDPRNWKBANNCNFSM4HHD7NNQ
.

내 이해에 oauthlib.common.Request 클래스에는 __getattr__ 메서드와 _params 사전(쿼리 문자열 및 본문 매개변수에서 업데이트됨) 및 client_secret 에 액세스/가져오려는 모든 요청 이 있습니다 client_secret 또는 code_verifier 는 본문 및/또는 헤더에서만 조회해야 합니다(민감한 데이터 조회를 위해 별도의 속성을 갖는 것이 합리적일 수 있음).

따라서 검사는 url이 설정될 때가 아니라 속성 액세스 시간에 이루어져야 합니까? 요청 속성이 초기화 시 한 번만 설정되면 모든 속성 액세스 대신 바로 검사를 수행할 수 있습니다. 각 속성 액세스에서 여전히 검사를 수행해야 한다고 생각하면 알려주십시오.

이 문제가 더 크고 전체 /token 엔드포인트에 적용된다는 것을 알고 있습니다. 이 끝점은 URL의 매개변수를 허용해서는 안 됩니다(MUST NOT). 그것은 허용되어서는 안됩니다.

내성 엔드포인트도 적합하다고 생각합니다. IIRC에 따르면
HTTP 사양, POST 요청은 항상 쿼리 매개변수를 무시해야 합니다. 만약에
우리는 영향을 미치지 않고 모든 문제를 자동으로 해결합니다.
유효한 사용 사례. 다른 HTTP 동사가 어떻게 동작해야 하는지 잘 모르겠습니다.
그러나 나는 POST 하나에 대해 확신합니다. 그게 맞는지 누가 확인할 수 있나요
나아가야 할 방향은?

>

모든 POST에 대한 모든 쿼리 매개변수를 거부하는 것은 매력적인 지름길입니다! 그러나 oauthlib의 ResourceEndpoint와 일부 사용자가 여전히 URL에 쿼리 인수를 추가할 수 있다는 사실이 걱정됩니다(권장되지는 않지만 기술적으로 여전히 가능함).

리소스 엔드포인트에 대한 우려 사항에 대해 좀 더 자세히 설명해 주시겠습니까?

내가 볼 때 POST 요청은 양식 제출 또는 API를 통해 이루어집니다.
호출(명시적 코드 작성). 누군가가 부분을 추가하는 이유를 모르겠습니다.
데이터를 쿼리 매개변수로, 부분 데이터를 포스트 데이터로 사용합니다. 사실, 더 쉽게
둘 중 하나에 완전히 전념하십시오.
실제로 라이브러리를 사용하여 요청을 하는 경우 훨씬 더 쉽습니다.
모든 것을 분할하는 대신 포스트 본문으로 추가하십시오.

설명 오류가 표시되는 경우 POST에 쿼리 매개변수를 추가하는 사용자,
빨리 자가 교정할 수 있어야 합니다.

또는 적용할 때 믹스인이나 데코레이터를 만들 수 있습니다.
쿼리 매개변수가 있는 POST 요청에 대한 오류입니다.

이에 대한 또 다른 가능한 솔루션이 있습니다. 끝점의 경우( AuthorizationEndpoint , IntrospectEndpoint , RevocationEndpoint ); 요청 방법이 POST 해당 요청 유효성 검사 방법에 쿼리 매개변수 검사를 추가할 수 있습니다. ( TokenEndpoint , MetadataEndpoint )의 경우 체크인 응답 생성 방법을 추가할 수 있습니다.
또는 일관성을 위해 모든 응답 생성 방법 내부에 검사 메커니즘을 추가할 수 있습니다. 좋은 생각 같나요?

_request_ 유효성 검사 방법을 사용하는 것이 바람직하다고 생각합니다.
POST 는 TokenEndpoint , IntrospectEndpoint 및 RevocationEndpoint 에만 해당됩니다. 다른 것들은 GET : AuthorizationEndpoint , MetadataEndpoint 입니다.

일반적인 의견: 민감한 필드에 집중해야 합니까(예: 블랙리스트 유지) 아니면 모든 OAuth2 매개변수를 거부해야 하나요(우리는 NONE이 쿼리 URI에 있기를 원합니다. 맞습니까?)

이상적으로는 쿼리 URI에 NONE을 원합니다. 나는 블랙리스트에 갔지
기존 사용 사례를 위반할 수 있는지 확인합니다. OAuth2가 없을 뿐만 아니라
매개변수는 허용되지만 쿼리 매개변수는 전혀 허용되지 않습니다.

>

요청에서 끝점으로 검사를 이동하면 해당 끝점에 대한 모든 쿼리 매개 변수를 비활성화하는 데 문제가 없습니다!

알겠습니다. 정확한 엔드포인트에서 모든 쿼리 매개변수를 비활성화하겠습니다. 그리고
또한 http 메소드를 POST로 제한하고 있습니다. 맞습니까?

https://github.com/oauthlib/oauthlib/pull/667 에서 수정되었습니다.

이 변경에 대한 이유는 이해하지만 client_secret 를 쿼리 매개변수로 보내는 클라이언트에 대한 주요 변경인 것 같습니다. 이전 버전과의 호환성이나 주요 버전 충돌을 예상했을 것입니다. 이 동작이 의도된 것입니까?

우리는 현재 django-oauth-toolkit을 사용하고 있으며 클라이언트는 username , password , client_secret , client_id 및 grant_type 를 쿼리로 보내고 있습니다. 매개변수. 모든 것을 POST 매개변수로 전송하도록 전환하면 unsupported_grant_type 오류가 발생합니다.

POST에 대한 쿼리 지원은 원하는 동작보다 더 많은 부작용입니다. 나는 그것이 당신의 클라이언트를 망가뜨린다는 것을 이해하므로 <3.1
또한 보안 문제가 포함되므로 최대한 빨리 업그레이드하는 것을 고려하십시오(비밀은 여러 의도하지 않은 위치에 걸쳐 로그, 프록시에 표시됨).