OAuth 2에서 암시 적 부여 권한 부여 유형의 목적은 무엇입니까?

나는 단지 어떤 종류의 사각 지대가 있는지 모르겠지만 OAuth 2 사양을 여러 번 읽었고 메일 링리스트 아카이브를 읽었으며 암묵적 보조금이 왜 필요한지에 대한 좋은 설명을 찾지 못했습니다. 액세스 토큰을 얻기위한 흐름이 개발되었습니다. Authorization Code Grant와 비교할 때 강력한 이유없이 클라이언트 인증을 포기하는 것 같습니다. "스크립팅 언어를 사용하여 브라우저에서 구현 된 클라이언트에 어떻게 최적화되어 있습니까?"

두 흐름 모두 동일하게 시작됩니다 (출처 : http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ) :

1. 클라이언트는 자원 소유자의 사용자 에이전트를 권한 부여 엔드 포인트로 지정하여 플로우를 시작합니다.
2. 권한 부여 서버는 (사용자 에이전트를 통해) 자원 소유자를 인증하고 자원 소유자가 클라이언트의 액세스 요청을 승인 또는 거부하는지 여부를 설정합니다.
3. 자원 소유자가 액세스 권한을 부여한다고 가정하면 권한 부여 서버는 이전에 제공된 (요청시 또는 클라이언트 등록 중에) 리디렉션 URI를 사용하여 사용자 에이전트를 클라이언트로 다시 리디렉션합니다.
   • 리디렉션 URI에는 인증 코드 (인증 코드 흐름)가 포함되어 있습니다.
   • 리디렉션 URI에는 URI 조각에 액세스 토큰이 포함됩니다 (암시 적 흐름)

흐름이 분할되는 곳입니다. 두 경우 모두이 시점에서 리디렉션 URI는 클라이언트가 호스트하는 일부 엔드 포인트에 대한 것입니다.

• 권한 부여 코드 플로우에서 사용자 에이전트가 URI의 권한 부여 코드를 사용하여 해당 엔드 포인트에 도달하면 해당 엔드 포인트의 코드가 클라이언트 신임 정보와 함께 권한 코드를 액세스 토큰에 대한 권한 코드와 교환하여 필요에 따라 사용할 수 있습니다. 예를 들어, 페이지의 스크립트가 액세스 할 수있는 웹 페이지에 쓸 수 있습니다.
• 암시 적 흐름은이 클라이언트 인증 단계를 모두 건너 뛰고 클라이언트 스크립트를 사용하여 웹 페이지를로드합니다. 여기에 액세스 토큰이 너무 많이 전달되지 않도록하는 URL 조각에는 귀여운 트릭이 있지만 최종 결과는 동일합니다. 클라이언트 호스팅 사이트는 액세스 토큰을 가져올 수있는 스크립트가있는 페이지를 제공합니다. .
  

따라서 내 질문 : 클라이언트 인증 단계를 건너 뛰면 무엇을 얻었습니까?

내 생각은 다음과 같습니다.

인증 코드 흐름에서 인증 코드 + 토큰의 목적은 토큰과 클라이언트 시크릿이 서버 간 이동하므로 리소스 소유자에게 노출되지 않도록하는 것입니다.

반면 암시 적 부여 흐름은 완전히 자바 스크립트를 사용하여 구현되고 리소스 소유자의 브라우저에서 실행되는 클라이언트를위한 것입니다. 이 흐름을 사용하기 위해 서버 측 코드가 필요하지 않습니다. 그런 다음 리소스 소유자의 브라우저에서 모든 일이 발생하면 토큰 및 클라이언트 시크릿은 여전히 ​​리소스 소유자와 공유되므로 인증 코드 및 클라이언트 시크릿을 더 이상 발행하지 않습니다. 인증 코드 및 클라이언트 비밀을 포함하면 실제 보안을 추가하지 않고도 흐름이 더 복잡해집니다.

"무엇을 얻었습니까?" "단순함"입니다.

보안상의 이유로 단순성이 아니라 있습니다.

사용자 에이전트 와 클라이언트 의 차이점을 고려해야합니다 .

사용자 에이전트는 사용자 ( "자원 소유자")가 시스템의 다른 부분 (인증 서버 및 자원 서버)과 통신하는 소프트웨어입니다.

클라이언트는 리소스 서버에서 사용자의 리소스에 액세스하려는 소프트웨어입니다.

사용자 에이전트와 클라이언트가 분리 된 경우 Authorization Code Grant 가 적합합니다. 예를 들어 사용자는 웹 브라우저 (사용자 에이전트)를 사용하여 킥 스타터에서 자신의 Facebook 계정으로 로그인합니다. 이 경우 클라이언트는 사용자 로그인을 처리하는 킥 스타터 서버 중 하나입니다. 이 서버는 Facebook에서 액세스 토큰과 새로 고침 토큰을받습니다. 따라서이 유형의 클라이언트는 액세스가 제한되어 "안전한"것으로 간주되어 토큰을 저장할 수 있으며 킥 스타터는 사용자의 리소스에 액세스하고 사용자 상호 작용없이 액세스 토큰을 새로 고칠 수 있습니다.

사용자 에이전트와 클라이언트가 결합 된 경우 (예 : 기본 모바일 애플리케이션, 자바 스크립트 애플리케이션) 암시 적 승인 워크 플로우 가 적용될 수 있습니다. 자격 증명을 입력하기 위해 리소스 소유자가 있어야하며 새로 고침 토큰을 지원하지 않습니다. 이 클라이언트가 나중에 사용하기 위해 액세스 토큰을 저장하면 다른 응용 프로그램이나 클라이언트 사용자가 토큰을 쉽게 추출 할 수 있으므로 보안 문제가됩니다. 새로 고침 토큰이 없으면이 방법은 사용자가없는 상태에서 사용자 리소스에 액세스하기위한 것이 아닙니다.

일반적인 설명은 JavaScript 클라이언트를 사용할 때 암시 적 부여가 구현하기 쉽다는 것입니다. 그러나 나는 이것이 잘못된 방법이라고 생각합니다. XMLHttpRequest를 통해 보호 된 리소스를 직접 요청하는 JavaScript 클라이언트를 사용하는 경우 암시 적 부여가 유일한 옵션이지만 덜 안전합니다. *

인증 코드 부여는 추가 보안을 제공하지만 보호 된 리소스를 요청하는 웹 서버가있는 경우에만 작동합니다. 웹 서버는 액세스 토큰을 저장할 수 있으므로 액세스 토큰이 인터넷에 노출 될 위험이 적으며 오랫동안 지속되는 토큰을 발행 할 수 있습니다. 또한 웹 서버는 신뢰할 수 있으므로 "새로 고침 토큰"을 부여 할 수 있으므로 이전 토큰이 만료되면 새 액세스 토큰을 얻을 수 있습니다.

그러나 인증 코드 흐름의 보안은 웹 서버가 사용자 인증 (로그인)으로 설정된 세션으로 보호되는 경우에만 작동합니다. 세션이 없으면 신뢰할 수없는 사용자는 client_id를 사용하여 웹 서버에 요청을 할 수 있으며 사용자에게 액세스 토큰이있는 것과 같습니다. 세션을 추가하면 인증 된 사용자 만 보호 된 리소스에 액세스 할 수 있습니다. client_id는 JS webapp의 "identity"일 뿐이며 해당 webapp의 인증은 아닙니다.

또한 OAuth 토큰이 만료되기 전에 세션을 종료 할 수 있습니다. 액세스 토큰을 무효화하는 표준 방법은 없습니다. 그러나 세션이 만료되면 웹 서버 외에는 아무도 알지 못하므로 액세스 토큰은 쓸모가 없습니다. 신뢰할 수없는 사용자가 세션 키에 액세스 할 수 있으면 세션이 유효한 동안에 만 보호 된 리소스에 액세스 할 수 있습니다.

웹 서버가 없으면 암시 적 부여를 사용해야합니다. 그러나 이것은 액세스 토큰이 인터넷에 노출되어 있음을 의미합니다. 신뢰할 수없는 사용자가 액세스하면 만료 될 때까지 사용할 수 있습니다. 즉, 인증 코드 부여보다 더 오래 액세스 할 수 있습니다. 따라서 토큰이 더 빨리 만료되도록하고 더 민감한 리소스에 액세스하지 않는 것이 좋습니다.

* 편집 : 최근에는 사람들이 서버가없는 웹 응용 프로그램에서도 암시 적 부여를 사용하지 않는 것이 좋습니다. 대신 PKCE와 함께 비어있는 비밀로 구성된 권한 부여 코드 부여를 사용할 수 있습니다. 인증 코드 부여는 브라우저 기록에 액세스 토큰을 저장하지 않도록하고, 누군가가 인증 URL을 도용하기 위해 리디렉션 URL을 가로채는 경우 PKCE가이를 노출하지 않도록합니다. 이 경우 클라이언트가 안전하게 저장할 수 없기 때문에 새로 고침 토큰을 반환하지 않도록 서버가 필요합니다. 그리고 위에서 언급 한 것과 동일한 제한으로 액세스 토큰을 발행해야합니다.

서버 측 구성 요소가없는 브라우저 기반 또는 "공용"(JavaScript) 웹 앱을 실행하는 사용자 는 앱 (및 브라우저가 실행되는 브라우저, 잠재적으로 다른 브라우저)을 암시 적으로 신뢰 합니다. 기반 앱 ...).

타사 원격 서버는없고 리소스 서버 만 있습니다. 사용자를 대신하여 작동하는 브라우저 외에 다른 에이전트 가 없기 때문에 인증 코드에는 이점이 없습니다 . 같은 이유로 클라이언트 자격 증명에는 이점이 없습니다. ( 모든 클라이언트는이 흐름을 사용할 수 있습니다.)

그러나 보안상의 의미는 중요합니다. 에서 http://tools.ietf.org/html/rfc6749#section-10.3 :

암시 적 부여 유형을 사용하는 경우 액세스 토큰이 URI 조각으로 전송되어 승인되지 않은 당사자에게 노출 될 수 있습니다.

에서 http://tools.ietf.org/html/rfc6749#section-10.16 :

리소스 소유자는 공격자의 악의적 인 클라이언트에게 액세스 토큰을 부여하여 리소스에 대한 액세스 권한을 기꺼이 위임 할 수 있습니다. 피싱 또는 다른 구실로 인한 것일 수 있습니다.

나는 대답과 Dan의 의견을 올바르게 이해하고 있는지 확실하지 않습니다. 그 대답은 일부 사실이 정확하다고 말했지만 OP가 요청한 것을 정확하게 지적합니다. 올바르게 이해하면 암시 적 부여 흐름의 주요 장점은 JS 앱과 같은 클라이언트 (예 : Chrome 확장 프로그램)가 클라이언트 비밀번호를 노출 할 필요가 없다는 것입니다.

댄 타 플린은 이렇게 말했다.

... 권한 부여 코드 흐름에서 리소스 소유자는 액세스 토큰을 볼 필요가 없지만 Javascript 클라이언트에서는 피할 수 없습니다. 그러나 인증 코드 흐름을 사용하여 클라이언트 비밀을 Javascript 클라이언트로부터 계속 유지할 수 있습니다.

어쩌면 나는 당신을 오해했지만 클라이언트 (이 경우 JS 응용 프로그램)는 인증 코드 흐름의 클라이언트 자격 증명 (클라이언트 키 및 비밀)을 리소스 서버에 전달해야합니다. 클라이언트 시크릿은 "JS에서 유지"할 수 없습니다.

Implicit Grant 는 클라이언트 측 JavaScript 응용 프로그램을 포함하여 클라이언트 암호를 보호 할 수없는 응용 프로그램을 지원하도록 설계 되었지만 일부 공급자는 대신 클라이언트 암호없이 인증 코드를 사용하여 대안을 구현하고 있습니다. OAuth 2.0 IETF RFC-6749 는 2012 년에 발표되었으며 최근 권장 사항은 2017 년에 발표되었습니다.

IETF OAuth 메일 링리스트에 대한 2017 년 토론은 다음 구현 자들로부터 얻을 수 있습니다 :

• 레드햇 : https://www.ietf.org/.../oauth/current/msg16966.html
• 도이치 텔레콤 : https://www.ietf.org/.../oauth/current/msg16968.html
• 스마트 헬스 IT : https://www.ietf.org/.../oauth/current/msg16967.html

더 많은 것을 읽으십시오 :

• https://aaronparecki.com/oauth-2-simplified/
• https://aaronparecki.com/oauth-2-simplified/#single-page-apps

암시 적은 비밀이없는 클라이언트에 대해 이전에 권장되었지만 비밀없이 권한 부여 코드 부여를 사용하여 대체되었습니다.

...

이전에는 브라우저 기반 앱이 액세스 토큰을 즉시 반환하고 토큰 교환 단계가없는 "암시 적"흐름을 사용하는 것이 좋습니다. 사양이 처음 작성된 이후 업계 모범 사례는 클라이언트 암호없이 인증 코드 흐름을 사용하도록 권장하도록 변경되었습니다. 이는 state 매개 변수 사용과 같은 보안 플로우를 작성할 수있는 더 많은 기회를 제공합니다. 참고 자료 : Redhat , Deutsche Telekom , Smart Health IT .

Implicit Grant의 클라이언트 시크릿없이 인증 코드로 이동하는 방법은 다음과 같은 모바일 앱에서도 언급됩니다.

• https://aaronparecki.com/oauth-2-simplified/#mobile-apps

다른 답변 외에도 암시 적 프로필을 통해 권한 부여 서버로 다시 전화를 걸어야하는 권한 부여 코드 흐름과 달리 프론트 채널 전용 흐름 만 허용됨을 인식해야합니다. 이것은 Auth 2.0 위에 구축 된 SSO 프로토콜 인 OpenID Connect에서 명백합니다. 암시 적 흐름은 널리 사용되는 SAML POST 바인딩과 비슷하고 권한 부여 코드 흐름은 덜 널리 배포 된 SAML 아티팩트 바인딩과 유사합니다.

암시 적 흐름에서 사용자의 브라우저가 손상된 경우 (evil extension / virus) 손상되면 사용자의 리소스에 액세스하여 나쁜 일을 할 수 있습니다.

인증 흐름에서 클라이언트 암호를 모르기 때문에 손상이 발생하지 않습니다.

https://tools.ietf.org/html/rfc6749#page-8

절대적인

암시 적 부여는 JavaScript와 같은 스크립팅 언어를 사용하여 브라우저에서 구현 된 클라이언트에 최적화 된 단순화 된 인증 코드 흐름입니다. 암시 적 플로우에서 클라이언트에게 권한 부여 코드를 발행하는 대신 클라이언트는 (소유자 권한 부여의 결과로) 액세스 토큰을 직접 발행합니다. 권한 부여 유형은 중간 자격 증명 (예 : 인증 코드)이 발행되지 않고 나중에 액세스 토큰을 얻는 데 사용되므로 암시 적입니다.

내재적 부여 플로우 동안 액세스 토큰을 발행 할 때
권한 부여 서버는 클라이언트를 인증하지 않습니다. 일부
의 경우, 클라이언트 ID는 URI가 리디렉션을 통해 확인할 수 있습니다
클라이언트에 액세스 토큰을 전달하는 데 사용됩니다. 액세스 토큰은 리소스 소유자 또는 사용자 에이전트에 대한 액세스 권한이있는 다른 응용 프로그램에 노출 될 수 있습니다.

암시 적 부여 는 액세스 토큰 을 얻는 데 필요한 왕복 횟수를 줄이므로 일부
클라이언트 (예 : 브라우저 내 응용 프로그램으로 구현 된 클라이언트) 의 응답 성과 효율성을 향상
시킵니다
.

Will Cain은 "같은 이유로 클라이언트 자격 증명에는 이점이 없습니다. (모든 클라이언트는이 흐름을 사용할 수 있습니다." 암시 적 플로우를 위해 Authorization Server에서 작성됩니다. 클라이언트를 사전 트러스트 할 방법이 없으므로 사용자는 사용자 클레임 릴리스를 승인해야합니다.

암시 적 그랜트에서 토큰 획득이 가능 권한 부여 엔드 포인트를 로모그래퍼 GET. 이는 권한 서버가 CORS를 지원할 필요가 없음을 의미합니다.

문제가되지 않고 권한 부여 서버와 관련된 다른 문제가없는 경우 (예 : 어떤 이유로 든 새로 고침 토큰은 선택 사항이 아님), 최근 업계 동향 에 따라 공개 클라이언트의 경우에도 권한 부여 코드 흐름이 선호됩니다 그리고 공식 초안의 적어도 (현재) 사례에 .

역사적으로 암시 적 흐름을 구현해야하는 다른 이유가 있었지만 현재 다음과 같은 권한 부여 코드 부여가 제공하는 보안상의 이점보다 중요합니다.

• 비밀 고객을 위해 백 채널을 통해 토큰을 제공하고 사용하는 옵션
• 공개 클라이언트의 브라우저 기록에 토큰을 노출시키지 않습니다.
• "모든 종류의 OAuth 클라이언트"에 대해 PKCE 와 함께 토큰이 발행되기 전에 승인되지 않은 흐름 중단

방금 OAuth 2.0에 대한 기사를 보았습니다. 저자는 암시 적 흐름의 배후에있는 이유는 요청에 JS 앱이 매우 제한되어 있기 때문이라고 말합니다.

암시 적 유형이 OAuth 2.0에 포함 된 이유가 궁금하다면 설명은 간단합니다. 동일한 출처 정책. 그 당시 프론트 엔드 응용 프로그램은 코드를 사용하여 액세스 토큰을 얻기 위해 다른 호스트로 요청을 보낼 수 없었습니다. 오늘은 CORS (Cross-Origin Resource Sharing)가 있습니다.

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611