OAuth 2.0에는 여러 워크 플로우가 있습니다. 두 가지에 대해 몇 가지 질문이 있습니다.

1. 인증 코드 흐름 -사용자가 클라이언트 앱에서 로그인하면 인증 서버가 인증 코드를 앱에 반환합니다. 그런 다음 앱은 인증 코드를 액세스 토큰으로 교환합니다.
2. 암시 적 부여 흐름 -사용자가 클라이언트 앱에서 로그인하면 권한 부여 서버가 클라이언트 앱에 직접 액세스 토큰을 발급합니다.

보안 측면에서 두 방법의 차이점은 무엇입니까? 어느 것이 더 안전하고 왜?

서버가 직접 액세스 토큰을 발행 할 수있을 때 추가 작업 단계 (토큰에 대한 교환 인증 코드)가 하나의 작업 흐름에 추가되는 이유를 알 수 없습니다.

다른 웹 사이트에서는 클라이언트 앱이 자격 증명을 안전하게 유지할 수있을 때 인증 코드 흐름이 사용된다고 말합니다. 왜?

는 access_token보호 된 자원 (API를) 호출 할 필요가 것입니다. 인증 코드 흐름에는 두 가지 단계가 있습니다.

1. 사용자는를 인증하고 codeAPI 소비자 ( "클라이언트")에게 반환해야합니다 .
2. API를 (일반적으로 웹 서버)가이 교류의 "클라이언트" code에 대한 # 1에서 얻어진 access_token, 자신을 인증하는 client_id과client_secret
3. 그런 다음로 API를 호출 할 수 있습니다 access_token.

따라서 이중 확인이 있습니다. API를 통해 노출 된 리소스를 소유 한 사용자와 API를 사용하는 클라이언트 (예 : 웹앱). 둘 다 액세스 권한이 부여되었는지 확인합니다. 여기서 OAuth의 "권한 부여"특성을 확인하십시오. 사용자는 code인증 후 반환을 통해 자신의 리소스에 대한 액세스 권한을 앱에 부여하고 앱을 가져 access_token오고 사용자를 대신하여 호출합니다.

암시 적 흐름에서, 단계 2는 생략된다. 따라서 사용자 인증 후에 access_token는 리소스에 액세스하는 데 사용할 수있는가 직접 반환됩니다. API는 누가 해당 API를 호출하는지 모릅니다. access_token캔을 가진 사람은 누구나 앞의 예제에서는 웹 앱만 사용할 수 있습니다 (일반적으로 내부자는 누구나 액세스 할 수 없음).

암시 적 흐름은 일반적으로 저장 client id하고 client secret권장하지 않는 시나리오에서 사용됩니다 (예를 들어, 많은 사람들이 사용하지만 장치). 그것이 면책 조항의 의미입니다. 사람들은 클라이언트 코드에 액세스 할 수 있으므로 자격 증명을 얻어 리소스 클라이언트가 될 수 있습니다. 암시 적 흐름에서 모든 데이터는 일시적이며 앱에는 아무것도 저장되지 않습니다.

위의 답변에서 명확하지 않다고 생각되는 것을 여기에 추가하겠습니다.

• Authorization-Code-Flow를 사용하면 최종 액세스 토큰 이 브라우저 / 앱을 사용하여 머신에 절대 도달하지 않으며 저장되지 않습니다 . 임시 인증 코드는 브라우저 / 앱이있는 머신에 제공되며 서버로 전송됩니다. 그런 다음 서버는 전체 액세스 토큰으로 교환하고 API 등에 액세스 할 수 있습니다. 브라우저가있는 사용자는 토큰이있는 서버를 통해서만 API에 액세스 할 수 있습니다.
• 암시 적 흐름에는 두 당사자 만 참여할 수 있으며 최종 액세스 토큰은 브라우저 / 앱과 함께 클라이언트에 저장됩니다. 이 브라우저 / 앱이 손상되면 인증 토큰이 위험 할 수 있습니다.

TL; DR은 당신이 보류 토큰에 사용자의 컴퓨터를 신뢰하지 않는 경우 암시 적 흐름을 사용하지 않는하지만 당신은 어떻게 당신의 자신의 서버를 신뢰합니다.

둘의 차이점은 다음과 같습니다.

1. 암시 적 흐름에서 토큰은 "#"기호가있는 리디렉션 URL을 통해 직접 반환되며 이는 자체 서버 측이없는 자바 스크립트 클라이언트 또는 모바일 응용 프로그램에서 주로 사용되며 클라이언트는 일부 구현에서 비밀을 제공 할 필요가 없습니다. .

2. 인증 코드 흐름에서 코드는 "?"와 함께 반환됩니다. 서버 측에서 읽을 수 있도록 서버 측은 권한 부여 서버에서 json 객체로 토큰을 가져 오기 위해 이번에 토큰 URL에 클라이언트 비밀을 제공해야합니다. 이를 처리하고 자신의 시스템에 자신의 프로필과 함께 사용자 토큰을 저장할 수있는 응용 프로그램 서버가있는 경우에 사용되며 주로 일반적인 모바일 응용 프로그램에 사용됩니다.

따라서 클라이언트 응용 프로그램의 특성에 따라 달라집니다. 클라이언트에 대한 비밀을 요청하고 매우 안전한 연결을 통해 권한 부여 서버와 클라이언트 응용 프로그램간에 토큰을 전송할 수있는 하나 이상의 안전한 "권한 부여 코드"가 있습니다. 일부 클라이언트가 "권한 부여 코드"만 사용하도록 제한하고 암시 적 허용 안 함

암시 적 부여는 인증 코드 부여와 유사하며 두 가지 차이점이 있습니다.

모든 애플리케이션 코드 및 스토리지에 쉽게 액세스 할 수 있기 때문에 클라이언트를 비밀로 유지할 수없는 사용자 에이전트 기반 클라이언트 (예 : 단일 페이지 웹 앱)에 사용됩니다.

둘째, 인증 서버가 액세스 토큰과 교환 된 인증 코드를 반환하는 대신 인증 서버는 액세스 토큰을 반환합니다.

자세한 내용은 여기를 참조하십시오 http://oauth2.thephpleague.com/authorization-server/which-grant/

암시 적 흐름

장점

• 가장 간단한 구현

단점

• 브라우저에 보이는 액세스 토큰
• 액세스 토큰의 출처를 결정할 수 없습니다
• 액세스 토큰은 만료 될 수 없습니다 (Google 정책에 따라)

인증 코드 흐름

장점

• 가장 안전한
• 공유 암호를 알고있는 경우에만 액세스 토큰 및 새로 고침 토큰을 만들 수 있습니다
• 새로운 보안 및 UX 기능을 사용할 수있게되면 향상 될 수 있습니다

단점

• 여러 인증 엔드 포인트를 구현해야합니다.

인용 : https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

위의 답변에서 배운 요점을 요약하고 내 자신의 이해를 추가하겠습니다.

인증 코드 흐름 !!!

• OAuth 클라이언트 역할을하는 웹 애플리케이션 서버가있는 경우
• 오래 살기 원한다면
• 데이터에 오프라인으로 액세스하려는 경우
• 앱의 API 호출에 대한 책임이있는 경우
• OAuth 토큰을 유출하지 않으려는 경우
• 데이터에 액세스해야 할 때마다 권한 부여 흐름을 통해 응용 프로그램을 실행하지 않으려면 참고 : 암시 적 부여 흐름은 새로 고침 토큰을 입력하지 않으므로 권한 부여 서버가 액세스 토큰을 정기적으로 만료하는 경우 액세스가 필요할 때마다 권한 부여 흐름을 통해 응용 프로그램을 실행해야합니다.

암묵적 보조금 흐름 !!!

• OAuth 클라이언트 역할을하는 웹 응용 프로그램 서버가없는 경우
• 오래 지속되는 액세스가 필요하지 않은 경우, 즉 데이터에 대한 임시 액세스 만 필요합니다.
• 앱이 실행되는 브라우저를 신뢰하고 신뢰할 수없는 사용자에게 액세스 토큰이 유출 될 우려는 제한적입니다.

어느 것이 더 안전하고 왜?

둘 다 안전합니다. 사용중인 환경에 따라 다릅니다.

서버가 직접 액세스 토큰을 발행 할 수있을 때 추가 작업 단계 (토큰에 대한 교환 인증 코드)가 하나의 작업 흐름에 추가되는 이유를 알 수 없습니다.

간단하다. 클라이언트가 안전하지 않습니다. 자세히 보자.

에 대한 애플리케이션을 개발하고 있다고 가정 Instagram API하여 APP을 등록 Instagram하고 API's필요한 것을 정의 하십시오 . Instagram를 제공 할 것입니다 client_id및client_secrect

당신은 웹 사이트에 링크를 설정합니다. "내 신청서를 가져 와서 사용하십시오". 이 웹 응용 프로그램을 클릭하면를 두 번 호출해야 Instagram API합니다.

FirstInstagram Authentication Server아래 매개 변수 로 요청을 보내 십시오.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

을 (를) 보내지client_secret 않습니다. 클라이언트 (응용 프로그램을 사용하려고하는 사용자 및 / 또는 브라우저)를 신뢰할 수 없습니다. 클라이언트는 url 또는 java 스크립트를보고 client_secrect쉽게 찾을 수 있습니다. 이것이 또 다른 단계가 필요한 이유입니다.

code및을 받습니다 state. code이곳은 temporary어떤 곳 저장되지 않습니다.

그런 다음 서버에서 second전화를 겁니다.Instagram API

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

서버에서 전화를 걸면 사용자가 리소스 사용 권한을 부여한 것을 client_secret보여주는 안전하게 사용할 수 있습니다 .codeclient_id

이에 대한 응답으로 access_token

실용적인 관점에서 (내가 이해 한 것), Authz 코드 흐름을 갖는 주된 이유는 다음과 같습니다.

1. 암시 적으로 지원되지 않는 새로 고침 토큰 지원 (사용자를 대신하여 앱의 장기 액세스) : https://tools.ietf.org/html/rfc6749#section-4.2
2. 리소스 소유자가 제공 할 액세스 권한을 제어 할 수있는 동의 페이지 지원 (Google에 표시되는 권한 / 권한 페이지). 묵시적인 것도 없습니다. https://tools.ietf.org/html/rfc6749#section-4.1 섹션 (B)를 참조하십시오.

"권한 부여 서버는 사용자 에이전트를 통해 자원 소유자를 인증하고 자원 소유자가 클라이언트의 액세스 요청을 승인 또는 거부하는지 여부를 설정합니다."

그 외에도 앱은 새로 고침 토큰을 사용하여 사용자 데이터에 장기적으로 액세스 할 수 있습니다.

지금까지 논의되지 않은 두 가지 핵심 사항이있는 것 같습니다. 인증 코드 부여 유형의 우회가 보안을 추가하는 이유를 설명합니다.

짧은 이야기 : 인증 코드 부여 유형은 브라우저 기록에서 중요한 정보를 유지하며 토큰 전송은 인증 서버의 HTTPS 보호에만 의존합니다.

더 긴 버전 :

다음에서는 RFC에 정의 된 OAuth 2 용어 (빠른 읽기) 인 resource server , client , authorization server , resource owner를 사용 합니다.

일부 타사 앱 (= 클라이언트)이 Google 계정의 특정 데이터 (= 리소스 서버)에 액세스하려고한다고 상상해보십시오. Google이 OAuth 2를 사용한다고 가정 해 보겠습니다. 귀하는 Google 계정의 리소스 소유자이지만 지금은 타사 앱을 운영하고 있습니다.

먼저 클라이언트가 브라우저를 열어 Google 인증 서버의 보안 URL로 사용자를 보냅니다. 그런 다음 액세스 요청을 승인하면 권한 부여 서버가 쿼리 문자열에 권한 부여 코드와 함께 이전에 제공된 클라이언트의 리디렉션 URL로 사용자를 다시 보냅니다. 이제 두 가지 핵심 사항에 대해

1. 이 리디렉션의 URL은 브라우저 기록에 나타납니다 . 그래서 우리는 여기서 오래 살 수 있고 직접 사용할 수있는 액세스 토큰을 원하지 않습니다. 수명이 짧은 인증 코드는 역사상 덜 위험합니다. 내재적 부여 유형 은 토큰을 히스토리에 넣습니다.
2. 이 리디렉션의 보안은 Google 인증서가 아닌 클라이언트 의 HTTPS 인증서에 따라 다릅니다 . 따라서 우리는 클라이언트의 전송 보안을 추가 공격 경로로 사용합니다 (이를 피할 수 있으려면 클라이언트가 JavaScript가 아니어야합니다. 그렇지 않으면 코드가 네트워크를 통과하지 않는 조각 URL을 통해 인증 코드를 전송할 수 있습니다. 이 이유가 될 수있는 이유 암시 그랜트 유형, 않습니다 그 때문에 더 이상 없다하더라도, 자바 스크립트 클라이언트에 대한 권장하기 위해 사용되는 조각 URL을 사용합니다.)

권한 부여 코드 부여 유형을 사용하면 클라이언트에서 권한 부여 서버로의 호출에 의해 토큰이 최종적으로 얻어집니다. 여기서 전송 보안 은 클라이언트가 아닌 권한 부여 서버 에만 의존합니다 .