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

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는 타사 앱이 계정 및 비밀번호없이 다른 웹 사이트에 저장된 데이터에 액세스 할 수있는 프로토콜입니다. 보다 공식적인 정의는 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 응용 프로그램에서 두 이메일을 모두 읽을 수 있습니다.

The reason OAuth exists is because it is unsecure for GMail to store your Yahoo username and password.

---

The other answer is very detailed and addresses the bulk of the questions raised by the OP.

To elaborate, and specifically to address the OP's question of "How does OAuth 2 protect against things like replay attacks using the Security Token?", there are two additional protections in the official recommendations for implementing OAuth 2:

1) Tokens will usually have a short expiration period (http://tools.ietf.org/html/rfc6819#section-5.1.5.3):

A short expiration time for tokens is a means of protection against the following threats:

• replay...

2) When the token is used by Site A, the recommendation is that it will be presented not as URL parameters but in the Authorization request header field (http://tools.ietf.org/html/rfc6750):

Clients SHOULD make authenticated requests with a bearer token using the "Authorization" request header field with the "Bearer" HTTP authorization scheme. ...

The "application/x-www-form-urlencoded" method SHOULD NOT be used except in application contexts where participating browsers do not have access to the "Authorization" request header field. ...

URI Query Parameter... is included to document current use; its use is not recommended, due to its security deficiencies

---

Here is perhaps the simplest explanation of how OAuth2 works for all 4 grant types, i.e., 4 different flows where the app can acquire the access token.

Similarity

All grant type flows have 2 parts:

• Get access token
• Use access token

The 2nd part 'use access token' is the same for all flows

Difference

The 1st part of the flow 'get access token' for each grant type varies.

However, in general the 'get access token' part can be summarized as consisting 5 steps:

1. Pre-register your app (client) with OAuth provider, e.g., Twitter, etc. to get client id/secret
2. Create a social login button with client id & required scopes/permissions on your page so when clicked user gets redirected to OAuth provider to be authenticated
3. OAuth provider request user to grant permission to your app (client)
4. OAuth provider issues code
5. App (client) acquires access token

Here is a side-by-side diagram comparing how each grant type flow is different based on the 5 steps.

This diagram is from https://blog.oauth.io/introduction-oauth2-flow-diagrams/

Each have different levels of implementation difficulty, security, and uses cases. Depending on your needs and situation, you will have to use one of them. Which to use?

Client Credential: If your app is only serving a single user

Resource Owner Password Crendential: This should be used only as last resort as the user has to hand over his credentials to the app, which means the app can do everything the user can

인증 코드

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

암시 적

: 앱이 모바일 또는 단일 페이지 앱인 경우여기에 선택에 대한 자세한 설명이 있습니다 :

https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

참고 URL :

https://stackoverflow.com/questions/4727226/how-does-oauth-2-protect-against-things-like-replay-attacks-using-the-security-t

도움이 되겠다면 ↓↓↓ 배너 한번만 클릭 해주시면 감사합니다 ^^