OAuth 2는 OAuth 1과 어떻게 다릅니 까?

매우 간단한 용어로 누군가 OAuth 2와 OAuth 1의 차이점을 설명 할 수 있습니까?

OAuth 1은 이제 더 이상 사용되지 않습니까? OAuth 2를 구현해야합니까? OAuth 2의 구현이 많지 않습니다. 대부분은 여전히 ​​OAuth 1을 사용하고 있으므로 OAuth 2를 사용할 준비가되어 있지 않은 것 같습니다. 그렇습니까?

Eran Hammer-Lahav는 자신의 Otro 2.0 소개 기사의 차이점을 설명하는 데 훌륭한 역할을 수행했습니다 . 요약하면 다음과 같은 주요 차이점이 있습니다.

브라우저 기반이 아닌 응용 프로그램을 더 잘 지원할 수있는 더 많은 OAuth 흐름. 이것은 브라우저 기반이 아닌 클라이언트 응용 프로그램의 OAuth에 대한 주된 비판입니다. 예를 들어 OAuth 1.0에서 데스크톱 응용 프로그램 또는 휴대폰 응용 프로그램은 사용자에게 브라우저를 원하는 서비스로 열고 서비스를 인증하고 서비스에서 응용 프로그램으로 토큰을 다시 복사하도록 지시해야했습니다. 여기서 중요한 비판은 사용자 경험에 대한 것입니다. OAuth 2.0에서는 애플리케이션이 사용자에 대한 권한을 얻는 새로운 방법이 있습니다.

OAuth 2.0은 더 이상 클라이언트 응용 프로그램에 암호화가 필요하지 않습니다. 이는 HMAC 해시 토큰 및 요청 문자열에 대한 애플리케이션이 필요하지 않은 이전 Twitter Auth API로 되돌아갑니다. OAuth 2.0을 사용하면 응용 프로그램은 HTTPS를 통해 발급 된 토큰 만 사용하여 요청할 수 있습니다.

OAuth 2.0 서명은 훨씬 덜 복잡합니다. 더 이상 특별한 구문 분석, 정렬 또는 인코딩이 필요하지 않습니다.

OAuth 2.0 액세스 토큰은 "짧습니다". 일반적으로 OAuth 1.0 액세스 토큰은 1 년 이상 보관할 수 있습니다 (Twitter는이를 만료시키지 않음). OAuth 2.0에는 새로 고침 토큰이라는 개념이 있습니다. 나는 이것이 무엇인지 완전히 확신하지는 않지만, 귀하의 액세스 토큰은 수명이 짧을 수 있지만 세션 기반으로 갱신 토큰은 "수명"일 수 있습니다. 사용자가 응용 프로그램을 다시 인증하지 않고 새로 고침 토큰을 사용하여 새 액세스 토큰을 얻습니다.

마지막으로 OAuth 2.0은 OAuth 요청을 처리하는 서버와 사용자 권한을 처리하는 서버 사이에서 역할을 완전히 분리해야합니다. 이에 대한 자세한 내용은 앞에서 설명한 기사에 자세히 설명되어 있습니다.

나는 큰 응답을 여기를 참조하지만 스프링 프레임 워크 I로 일해야했다 I 미스 일부 다이어그램을했고, 무엇 때문에이 우연히 자신의 설명 .

다음 다이어그램이 매우 유용합니다. OAuth2 및 OAuth1과의 당사자 간 통신 차이를 보여줍니다.

OAuth 2

OAuth 1

이전의 설명은 모두 지나치게 상세하고 복잡한 IMO입니다. 간단히 말해 OAuth 2는 보안을 HTTPS 프로토콜로 위임합니다. OAuth 1은이를 요구하지 않았으며 결과적으로 다양한 공격을 처리 할 수있는 대체 방법이있었습니다. 이러한 방법을 사용하려면 애플리케이션이 복잡하고 구현하기 어려운 특정 보안 프로토콜을 사용해야합니다. 따라서 보안을 위해 HTTPS를 사용하는 것이 더 간단하므로 응용 프로그램 개발자는 걱정할 필요가 없습니다.

다른 질문에 대해서는 대답이 다릅니다. 일부 서비스는 HTTPS 사용을 원하지 않거나 OAuth 2 이전에 개발되었거나 OAuth 2를 사용하지 못하게하는 다른 요구 사항이 있습니다. 또한 OAuth 2 프로토콜 자체에 대해 많은 논쟁이있었습니다. 보시다시피 Facebook, Google 및 기타 일부는 각각 약간 다른 버전의 프로토콜이 구현되어 있습니다. 따라서 일부 사람들은 OAuth 1을 고수합니다. 플랫폼마다 더 균일하기 때문입니다. 최근에 OAuth 2 프로토콜이 완성되었지만 아직 채택 방법을 아직 알지 못했습니다.

Oauth 2 사용에 대한 심각한 보안 주장이 있습니다.

황량한 기사

더 기술적 인 것

이것들은 Oauth 2의 수석 저자가 제공합니다.

키 포인트:

• Oauth 2는 SSL을 기반으로 보안을 제공하지 않지만 Oauth 1은 전송에 독립적입니다.

• 어떤 의미에서 SSL은 서버가 연결을 확인하지 않고 일반 클라이언트 라이브러리가 실패를 쉽게 무시할 수 있다는 점에서 안전하지 않습니다.

  SSL / TLS의 문제점은 클라이언트 측에서 인증서를 확인하지 못하면 연결이 여전히 작동한다는 것입니다. 오류를 무시할 때마다 성공으로 이어 지므로 개발자는 바로 그렇게 할 것입니다. 서버는 인증서 확인을 시행 할 방법이 없으며, 가능하더라도 공격자가 그렇게하지 않을 것입니다.

• OAuth 1.0에서는 수행하기가 훨씬 어려운 모든 보안 기능을 제거 할 수 있습니다.

  두 번째 일반적인 잠재적 문제는 오타입니다. 하나의 문자 ( 'https'에서 's')를 생략하면 토큰의 전체 보안이 무효화 될 때 적절한 디자인이라고 생각하십니까? 또는 유효하고 확인 된 SSL / TLS 연결을 통해 요청을 잘못된 대상 (예 : ' http://gacebook.com '? 커맨드 라인에서 OAuth 베어러 토큰을 사용할 수 있다는 것은 분명히 유스 케이스 베어러 토큰 옹호자가 홍보 한 것임을 기억하십시오.

OAuth 1.0 프로토콜 ( RFC 5849 )의 보안은 클라이언트 애플리케이션에 임베드 된 비밀 키를 기밀로 유지할 수 있다는 가정에 의존합니다. 그러나 가정은 순진합니다.

OAuth 2.0 ( RFC 6749 )에서는 이러한 순진한 클라이언트 응용 프로그램을 기밀 클라이언트 라고합니다 . 반면 비밀 키를 기밀로 유지하기 어려운 환경의 클라이언트 응용 프로그램을 공용 클라이언트 라고합니다 . 2.1을 참조하십시오 . 자세한 내용은 클라이언트 유형 을 참조하십시오.

그런 의미에서 OAuth 1.0은 기밀 클라이언트 전용 사양입니다.

" OAuth 2.0과 지옥으로가는 길 "에 따르면 OAuth 2.0의 보안 수준은 떨어지지 만 OAuth 1.0 클라이언트와 OAuth 2.0 기밀 클라이언트의 보안 수준에는 실질적인 차이가 없습니다. OAuth 1.0은 서명을 계산해야하지만 클라이언트 측의 비밀 키를 기밀로 유지할 수 있다고 확신하는 경우 보안을 강화하지 않습니다. 컴퓨팅 서명은 실질적인 보안 향상없이 ​​번거로운 계산입니다. 나는 TLS를 통해 서버와 단지 선물에의 OAuth 2.0 클라이언트 연결하는 단순성에 비해 의미 client_id하고 client_secret, 성가신 계산 보안의 측면에서 낫다는 것을 말할 수 없다.

또한 RFC 5849 (OAuth 1.0)에는 개방형 리디렉터 에 대한 언급이 없지만 RFC 6749 (OAuth 2.0)에는 없습니다. 즉, oauth_callbackOAuth 1.0의 매개 변수는 보안 허점이 될 수 있습니다.

따라서 OAuth 1.0이 OAuth 2.0보다 안전하다고 생각하지 않습니다.

OAuth 1.0 보안은 서명 계산에 의존합니다. 서명은 비밀 키가 HMAC-SHA1 ( RFC 5849, 3.4.2 ) 의 공유 키 또는 RSA-SHA1 ( RFC 5849, 3.4.3 ) 의 개인 키인 비밀 키를 사용하여 계산됩니다 . 비밀 키를 아는 사람은 누구나 서명을 계산할 수 있습니다. 따라서 비밀 키가 손상되면 서명 계산의 복잡성은 의미가 없지만 복잡합니다.

이는 OAuth 1.0 보안이 서명 계산의 복잡성과 논리에 의존하는 것이 아니라 비밀 키의 기밀성에만 의존한다는 것을 의미합니다. 즉, OAuth 1.0 보안에 필요한 것은 비밀 키를 기밀로 유지할 수있는 조건 일뿐입니다. 이것은 극단적으로 들릴지 모르지만 조건이 이미 만족되면 서명 계산으로 보안 향상이 추가되지 않습니다.

마찬가지로 OAuth 2.0 기밀 클라이언트도 동일한 조건에 의존합니다. 조건이 이미 만족되면 TLS를 사용하여 보안 연결을 작성하고 보안 연결을 통해 권한 부여 서버로 전송 client_id하고 문제점이 client_secret있습니까? OAuth 1.0과 OAuth 2.0 기밀 클라이언트간에 동일한 조건을 사용하는 경우 보안 수준에 큰 차이가 있습니까?

OAuth 1.0이 OAuth 2.0을 비난 할만한 이유를 찾을 수 없습니다. 실제로는 (1) OAuth 1.0은 기밀 클라이언트 전용 사양이며 (2) OAuth 2.0은 기밀 클라이언트 및 지원되는 공용 클라이언트 에 대한 프로토콜도 단순화했습니다 . 잘 알려 진지 여부에 관계없이 스마트 폰 응용 프로그램은 공용 클라이언트 ( RFC 6749, 9 ) 로 분류되며 OAuth 2.0의 이점이 있습니다.

토큰이 생성되면 실제 API 호출에는 OAuth 2.0 서명이 필요하지 않습니다. 하나의 보안 토큰 만 있습니다.

OAuth 1.0을 사용하려면 클라이언트가 각 API 호출마다 두 개의 보안 토큰을 보내야하며 둘 다 사용하여 서명을 생성해야합니다. 요청을 검증하려면 보호 자원 엔드 포인트가 클라이언트 신임 정보에 액세스 할 수 있어야합니다.

다음 은 OAuth 1.0과 2.0의 차이점과 작동 방식에 대해 설명합니다.

OAuth 2는 분명히 시간 낭비입니다 (많은 사람의 입에서 나온 것).

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

그는 다음과 같이 말합니다 (간단하게 편집하고 강조하기 위해 굵게 표시).

... 더 이상 OAuth 2.0 표준과 연결할 수 없습니다. 저는 수석 저자이자 편집자로서의 역할을 사임하고 사양에서 이름을 철회 한 후 실무 그룹을 떠났습니다. 3 년 동안 힘들게 일한 문서에서 내 이름을 제거하고 20 개가 넘는 초안은 쉽지 않았습니다. 내가 5 년 넘게 이끈 노력에서 벗어나기로 결심 한 것은 괴로웠다.

... 결국 OAuth 2.0이 잘못된 프로토콜이라는 결론에 도달했습니다. WS- * 불량 내가 더 이상 관련되고 싶지 않다는 것은 나쁘다. ... OAuth 1.0과 비교할 때 2.0 사양은 더 복잡하고 상호 운용성이 떨어지며 유용성이 떨어지며 불완전하며 가장 중요하게 덜 안전합니다.

분명히, 웹 보안에 대한 깊은 이해를 가진 개발자가 OAuth 2.0을 사용하면 안전한 구현이 될 것입니다. 그러나 지난 2 년간의 경험과 마찬가지로 대부분의 개발자는 2.0에서 안전하지 않은 구현을 생성 할 가능성이 높습니다.

고급 설명이 필요한 경우 두 사양을 모두 읽어보십시오.

https://oauth.net/core/1.0a/

https://oauth.net/2/

흐름 차이에 대한 명확한 설명이 필요한 경우 다음이 도움이 될 수 있습니다.

OAuth 1.0 흐름

1. 클라이언트 응용 프로그램은 Twitter와 같은 공급자에 등록합니다.
2. 트위터는 고객에게 해당 애플리케이션에 고유 한 "소비자 비밀"을 제공합니다.
3. 클라이언트 앱 은 고유 한 "소비자 비밀"을 사용 하여 모든 OAuth 요청을 Twitter에 서명 합니다 .
4. OAuth 요청이 잘못되었거나 데이터가 누락되었거나 부적절하게 서명 된 경우 요청이 거부됩니다.

OAuth 2.0 흐름

1. 클라이언트 응용 프로그램은 Twitter와 같은 공급자에 등록합니다.
2. 트위터는 고객에게 해당 애플리케이션에 고유 한“클라이언트 비밀”을 제공합니다.
3. 클라이언트 응용 프로그램 에는 일반적으로 http 헤더 와 같은 모든 요청 과 함께 "클라이언트 비밀" 이 포함 됩니다 .
4. OAuth 요청이 잘못되었거나 데이터가 누락되었거나 잘못된 비밀이 포함되어 있으면 요청이 거부됩니다.

출처 : https://codiscope.com/oauth-2-0-vs-oauth-1-0/

OAuth 2.0은 다음과 같은 방식으로 작업을 단순화 할 것을 약속합니다.

1. 토큰 생성에 필요한 모든 통신에 SSL이 필요합니다. 복잡한 서명이 더 이상 필요하지 않기 때문에 복잡성이 크게 줄어 듭니다.
2. 토큰이 생성되면 실제 API 호출에 서명이 필요하지 않습니다. 여기서 SSL을 강력히 권장합니다.
3. 토큰이 생성되면 OAuth 1.0에서는 클라이언트가 모든 API 호출마다 두 개의 보안 토큰을 보내고 둘 다 사용하여 서명을 생성해야했습니다. OAuth 2.0에는 보안 토큰이 하나만 있으며 서명이 필요하지 않습니다.
4. API를 구현하는 실제 서버 인 "리소스 소유자"가 프로토콜의 어느 부분을 구현하고 별도의 "인증 서버"에 의해 구현 될 수있는 부분이 명확하게 지정되어 있습니다. 이를 통해 Apigee와 같은 제품은 기존 API에 대해 OAuth 2.0 지원을보다 쉽게 ​​제공 할 수 있습니다.

출처 : http://blog.apigee.com/detail/oauth_differences

보안 관점에서 OAuth 1로갑니다. OAuth 2.0 및 지옥으로가는 길 참조

"현재 1.0을 성공적으로 사용하고 있다면 2.0을 무시하십시오. 1.0 이상의 실제 가치는 제공하지 않습니다 (클라이언트 개발자가 이미 1.0 서명을 알아 낸 것 같습니다).

이 공간을 처음 사용하고 자신을 보안 전문가라고 생각하는 경우 기능을 신중하게 검토 한 후 2.0을 사용하십시오. 전문가가 아닌 경우 1.0을 사용하거나 신뢰할 수있는 공급자의 2.0 구현을 복사하여 올바르게 제공하십시오 (Facebook의 API 문서는 시작하기에 좋은 장소입니다). 2.0은 대규모에 적합하지만 주요 작업을 수행하는 경우 사이트에 보안 전문가가있을 수 있습니다. "