OAuth 2는 보안 토큰을 사용한 재생 공격과 같은 것들로부터 어떻게 보호합니까?

내가 이해했듯이에서 OAuth 2에서 다음과 같은 일련의 이벤트가 발생하여 의 사용자 정보 Site-A에 액세스 합니다.Site-B

1. Site-A에 등록 Site-B하고 비밀과 ID를 얻습니다.
2. 때 사용자가 알 Site-A액세스 Site-B, 사용자가 전송됩니다 Site-B그들이 말해 어디에 Site-B그들이 것 참 좋아하는 줄 것을 Site-A특정 정보에 대한 권한을.
3. Site-B인증 코드와 함께 사용자를 (으)로 다시 리디렉션 Site-A합니다.
4. Site-A그런 다음 Site-B보안 토큰에 대한 대가 로 해당 인증 코드를 비밀과 함께 전달합니다 .
5. Site-A그런 다음 보안 토큰을 요청과 함께 번들하여 사용자Site-B 를 대신하여 요청합니다.

보안 및 암호화 측면에서이 모든 것이 어떻게 작동합니까? OAuth 2는 보안 토큰을 사용한 재생 공격과 같은 것들로부터 어떻게 보호합니까?

OAuth 2.0의 실제 작동 방식 :

나는 창에서 가장 맛있는 도넛을 보았을 때 출근길에 올라프 빵집에서 운전을했습니다. 그래서 안으로 들어가서 "도넛이 있어야 해요!" 그는 "30 달러가 될 것"이라고 말했다.

네, 도넛 한 개에 30 달러입니다! 맛 있어야합니다! 요리사가 갑자기“아니오! 나는 물었다 : 왜? 그는 은행 송금 만 허용한다고 말했다.

진심이야? 네, 그는 진지했습니다. 나는 거의 바로 그곳으로 걸어 갔지만 도넛이 내게 불렀다. "저는 맛있어요 ...". 도넛을 주문한 사람은 누구입니까? 나는 말했다.

그는 나에게 그의 이름이 적힌 메모 (도넛이 아닌 요리사)를 나눠 주었다. 그의 이름은 이미 메모에 있었으므로 그 말의 요점이 무엇인지 모르겠지만 괜찮습니다.

나는 1 시간 반을 내 은행으로 몰았다. 나는 그 메모를 텔러에게 건네 주었다. 나는 그녀의 올라프가 나를 보냈다고 말했다. 그녀는 저에게 "읽을 수 있습니다"라는 외모 중 하나를 주었다.

그녀는 내 메모를하고, 신분을 물었고, 돈을 얼마나 주면 좋을지 물었다. 나는 그녀에게 $ 30 달러를 말했다. 그녀는 낙서를하고 나에게 또 다른 메모를 건네 주었다. 이 숫자에는 많은 숫자가 있었는데, 그것이 그들이 메모를 추적하는 방법이라고 생각했습니다.

그 시점에서 나는 굶주리고 있습니다. 나는 한 시간 반 후에 서서히 올라와 올라프 앞에 서서 메모를 확장했다. 그는 그것을 가져 가서 살펴보고 "돌아 올게요"라고 말했다.

나는 그가 내 도넛을 받고 있다고 생각했지만 30 분 후에 나는 의심스러워지기 시작했다. 그래서 카운터 뒤에있는 사람에게 "Olaf는 어디에 있습니까?"라고 물었습니다. 그는 "돈을 얻으 러 갔다"고 말했다. "무슨 소리 야?" "그는 은행에 메모합니다".

허프 .. 그래서 올라프는 은행이 저에게 줬다는 기록을 가지고 은행으로 돌아와서 내 계좌에서 돈을 얻었습니다. 은행이 나에게 준 메모를했기 때문에 은행은 내가 말하고있는 사람이라는 것을 알았고, 은행과 이야기했기 때문에 그들은 단지 그에게 30 달러 만 주겠다고 알았습니다.

올라프가 내 앞에 서서 마침내 내 도넛 을 나에게 줬기 때문에 그것을 알아내는 데 오랜 시간이 걸렸다 . 내가 떠나기 전에 나는 "올라프, 당신은 항상 이런 식으로 도넛을 팔았습니까?"라고 물어야했습니다. "아니오, 저는 다르게 했어요."

허. 차에 걸어 가면서 전화가 울렸다. 나는 대답을 귀찮게하지 않았다, 아마 내 직업은 나를 해고 전화, 내 상사는 그런 ***입니다. 게다가, 나는 방금 겪었던 과정에 대해 생각했다.

Olaf가 계좌 정보를 제공하지 않고도 은행 계좌에서 30 달러를 인출 할 수있었습니다. 그리고 이미 은행에 $ 30 만 가져가도된다고 말했기 때문에 돈이 너무 많이 들지 않을까 걱정할 필요가 없었습니다. 그리고 은행은 그가 올라프에게 나에게 준 메모를했기 때문에 그가 올바른 사람이라는 것을 알았습니다.

알았어. 내 주머니에서 30 달러를 주겠다. 그러나 이제 그는 은행에 매주 $ 30를 가져 오라고 할 수 있다는 점을 알게되었으므로 빵집에 나타나서 더 이상 은행에 갈 필요가 없었습니다. 원한다면 전화로 도넛을 주문할 수도 있습니다.

물론 나는 그렇게하지 않을 것입니다. 도넛은 역겨 웠습니다.

이 접근 방식이 더 넓은 응용 프로그램인지 궁금합니다. 그는 이것이 그의 두 번째 접근법이라고 언급했습니다. Olaf 2.0이라고 부를 수 있습니다. 어쨌든 나는 집으로 돌아가는 것이 좋으며 새로운 일자리를 찾기 시작해야한다. 그러나 도시의 새로운 곳에서 딸기 쉐이크 중 하나를 얻기 전에는 그 도넛의 맛을 씻어 낼 무언가가 필요합니다.

내가 읽은 내용에 따라 다음과 같이 작동합니다.

질문에 요약 된 일반적인 흐름이 맞습니다. 2 단계에서 사용자 X가 인증되고 사이트 B가 사이트 B에 대한 사용자 X의 정보에 액세스 할 수있는 권한을 부여합니다. 4 단계에서 사이트는 자신의 비밀을 사이트 B로 다시 전달하여 인증 코드뿐만 아니라 자체를 인증합니다. (사용자 X의 액세스 토큰)을 요구하고 있습니다.

전반적으로 OAuth 2는 실제로 매우 간단한 보안 모델이며 암호화는 직접 적용되지 않습니다. 대신 비밀 및 보안 토큰은 모두 기본적으로 비밀번호이며 전체는 https 연결의 보안으로 만 보호됩니다.

OAuth 2는 보안 토큰 또는 비밀의 재생 공격에 대한 보호 기능이 없습니다. 대신, 사이트 B는 전적으로 이러한 항목을 책임지고 내 보내지 않도록하고 사이트가 전송되는 동안 https를 통해 전송되는 사이트 B에 의존합니다 (https는 URL 매개 변수를 보호합니다).

인증 코드 단계의 목적은 편의상 간단하며 인증 코드는 그 자체로 특별히 민감하지 않습니다. 사이트 B에 사용자 X의 액세스 토큰을 요청할 때 사이트 A에 대한 사용자 X의 액세스 토큰에 대한 공통 식별자를 제공합니다. 사이트 B에있는 사용자 X의 사용자 ID만으로는 작동하지 않았을 것입니다. 동시에 여러 사이트에 전달되기 위해 대기중인 많은 액세스 토큰이있을 수 있기 때문입니다.

OAuth는 3 자 앱이 계정 및 비밀번호없이 다른 웹 사이트에 저장된 데이터에 액세스 할 수있는 프로토콜입니다. 보다 공식적인 정의는 Wiki 또는 사양을 참조하십시오.

유스 케이스 데모는 다음과 같습니다.

1. LinkedIn에 로그인하여 내 Gmail 연락처에있는 친구를 연결하고 싶습니다. LinkedIn은이를 지원합니다. Gmail에서 보안 리소스 (내 gmail 연락처 목록)를 요청합니다. 그래서이 버튼을 클릭합니다 :
   

2. 계정과 비밀번호를 입력하면 웹 페이지가 팝업되고 Gmail 로그인 페이지가 표시됩니다.
   

3. 그런 다음 Gmail은 "동의"를 클릭하는 동의 페이지를 표시합니다.

4. 이제 LinkedIn에서 Gmail의 내 연락처에 액세스 할 수 있습니다.

아래는 위 예제의 순서도입니다.

1 단계 : LinkedIn은 Gmail Authorization Server에 토큰을 요청합니다.

2 단계 : Gmail 인증 서버가 리소스 소유자를 인증하고 사용자에게 동의 페이지를 표시합니다. (사용자는 아직 로그인하지 않은 경우 Gmail에 로그인해야합니다)

3 단계 : 사용자가 LinkedIn이 Gmail 데이터에 액세스하도록 요청합니다.

4 단계 : Gmail 인증 서버가 액세스 토큰으로 응답합니다.

5 단계 : LinkedIn은이 액세스 토큰으로 Gmail API를 호출합니다.

6 단계 : 액세스 토큰이 유효한 경우 Gmail 리소스 서버가 연락처를 반환합니다. (토큰은 Gmail 리소스 서버에서 확인합니다)

OAuth에 대한 자세한 내용은 여기 를 참조 하십시오 .

RFC6750 에서 해제 된 그림 1 :

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

이것이 Oauth 2.0의 작동 방식이며, 이 기사 에서 잘 설명되어 있습니다.

이것은 보석입니다.

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

아주 간단한 요약 :

OAuth는 다음과 같은 네 가지 역할을 정의합니다.

1. 자원 소유자
2. 고객
3. 리소스 서버
4. 인증 서버

귀하 (자원 소유자)에게 휴대폰이 있습니다. 여러 개의 다른 이메일 계정이 있지만 모든 이메일 계정을 하나의 앱에 포함 시키려고하므로 계속 전환 할 필요가 없습니다. 따라서 GMail (클라이언트)은 Yahoo의 Authorization Server를 통해 Yahoo 이메일 (Resource Server)에 액세스하도록 요청하므로 GMail 응용 프로그램에서 두 이메일을 모두 읽을 수 있습니다.

OAuth가 존재하는 이유는 GMail이 Yahoo 사용자 이름과 비밀번호를 저장하는 것이 안전하지 않기 때문입니다.

다른 답변은 매우 상세하며 OP가 제기 한 대부분의 질문을 다룹니다.

"OAuth 2가 보안 토큰을 사용한 재생 공격과 같은 것들로부터 어떻게 보호합니까?"라는 OP의 질문을 구체적으로 설명하기 위해 OAuth 2를 구현 하기위한 공식 권장 사항에는 두 가지 추가 보호 기능이 있습니다 .

1) 토큰은 일반적으로 만료 기간이 짧습니다 ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ).

토큰의 짧은 만료 시간은 다음 위협으로부터 보호하는 수단입니다.

• 다시 하다...

2) 사이트 A에서 토큰을 사용하는 경우 URL 매개 변수로 표시되지 않고 권한 부여 요청 헤더 필드 ( http://tools.ietf.org/html/rfc6750 )에 토큰이 표시되는 것이 좋습니다 .

클라이언트는 "베어러"HTTP 인증 체계와 함께 "인증"요청 헤더 필드를 사용하여 베어러 토큰으로 인증 된 요청을 작성해야합니다. ...

"application / x-www-form-urlencoded"방법은 참여 브라우저가 "Authorization"요청 헤더 필드에 액세스 할 수없는 응용 프로그램 컨텍스트를 제외하고는 사용하지 않아야합니다. ...

URI 쿼리 매개 변수 ...는 현재 사용을 문서화하기 위해 포함됩니다. 보안 결함으로 인해 사용하지 않는 것이 좋습니다

다음은 OAuth2가 4 가지 보조금 유형, 즉 앱이 액세스 토큰을 얻을 수있는 4 개의 다른 흐름에서 작동하는 방법에 대한 가장 간단한 설명입니다.

유사성

모든 보조금 유형 흐름에는 두 부분이 있습니다.

• 액세스 토큰 받기
• 액세스 토큰 사용

두 번째 부분 '사용 액세스 토큰' 은 모든 흐름에서 동일합니다.

차

각 부여 유형에 대한 흐름 '액세스 토큰 가져 오기' 의 첫 번째 부분은 다양합니다.

그러나 일반적으로 '액세스 토큰 받기' 부분은 5 단계로 구성됩니다.

1. OAuth 제공자 (예 : Twitter 등)에 앱 (클라이언트)을 사전 등록하여 클라이언트 ID / 비밀을 확보하십시오.
2. 클릭 한 사용자가 OAuth 공급자로 리디렉션되어 인증되도록 페이지에 클라이언트 ID 및 필수 범위 / 권한이있는 소셜 로그인 버튼을 만듭니다.
3. OAuth 공급자가 사용자에게 앱 (클라이언트)에 권한을 부여하도록 요청
4. OAuth 제공자 문제 코드
5. 앱 (클라이언트)이 액세스 토큰을 얻습니다.

다음은 5 단계를 기반으로 각 부여 유형 흐름이 어떻게 다른지 비교 한 단계별 다이어그램입니다.

이 다이어그램은 https://blog.oauth.io/introduction-oauth2-flow-diagrams/ 에서 가져온 것입니다.

각기 다른 수준의 구현 난이도, 보안 및 사용 사례가 있습니다. 필요와 상황에 따라 그 중 하나를 사용해야합니다. 어느 것을 사용해야합니까?

클라이언트 자격 증명 : 앱이 단일 사용자에게만 서비스하는 경우

리소스 소유자 비밀번호 자격 증명 : 사용자가 자신의 자격 증명을 앱에 전달해야하는 최후의 수단으로 만 사용해야합니다. 즉, 앱이 사용자가 할 수있는 모든 것을 할 수 있습니다

인증 코드 : 사용자 인증을 얻는 가장 좋은 방법

암시 적 : 앱이 모바일 또는 단일 페이지 앱인 경우

여기에 선택에 대한 자세한 설명이 있습니다 : https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/