[F-Lab 66해빗 페이백 챌린지 ]

[F-Lab 페이백 모각코 59일차] OAuth2 인증 절차

everydeveloper 2023. 9. 9. 23:37

OAuth 2.0

"OAuth 2.0"은 "Open Authorization 2.0"의 줄임말입니다.

  1. Open: 이는 프로토콜이 공개적으로 사용할 수 있다는 것을 의미합니다. 즉, 누구나 이 프로토콜을 사용하여 자신의 서비스나 애플리케이션에 적용할 수 있습니다.
  2. Authorization: 인증이 아닌 권한 부여를 의미합니다. OAuth는 사용자 대신 클라이언트가 리소스에 접근할 수 있도록 권한을 부여하는 방식으로 작동합니다. 인증(Authentication)은 사용자의 정체성을 확인하는 과정이며, 권한 부여(Authorization)는 특정 작업을 수행할 수 있는 권한을 부여하는 과정입니다.
  3. 2.0: 이는 OAuth 프로토콜의 두 번째 주요 버전임을 나타냅니다. 처음에는 OAuth 1.0이 있었으나 여러 문제와 한계 때문에 개선된 2.0 버전이 등장하게 되었습니다.

따라서, OAuth 2.0은 사용자의 권한을 다른 애플리케이션에 부여하기 위한 개방된 프로토콜의 두 번째 주요 버전을 의미합니다. 이 프로토콜을 통해, 사용자는 자신의 정보나 리소스에 대한 제한적인 접근 권한을 다른 서비스나 애플리케이션에 부여할 수 있게 됩니다.

OAuth 2.0의 주요 인증 절차는 다음과 같습니다:

  1. 권한 요청 (Authorization Request):
    • 클라이언트(제3의 애플리케이션)는 사용자를 리소스 소유자의 승인을 받기 위한 권한 서버(authorization server)로 리디렉션합니다.
    • 이 때 주로 로그인 화면이 나타나며, 사용자는 해당 애플리케이션에 자신의 데이터에 접근을 허용할지 결정하게 됩니다.
  2. 권한 부여 (Authorization Grant):
    • 사용자가 애플리케이션의 접근을 허용하면, 권한 서버는 클라이언트에게 권한 부여 코드(authorization code)를 발급합니다.
    • 이 코드는 짧은 시간 내에 액세스 토큰을 받기 위해 사용되며, 이 코드 자체로 리소스에 접근하는 것은 허용되지 않습니다.
  3. 토큰 요청 (Access Token Request):
    • 클라이언트는 권한 부여 코드를 포함하여 권한 서버에 액세스 토큰을 요청합니다.
    • 이 때 클라이언트 인증 정보(예: client ID, client secret)와 함께 요청이 이루어집니다.
  4. 토큰 발급 (Access Token Response):
    • 권한 서버는 클라이언트의 요청을 검증한 후, 유효하다고 판단되면 액세스 토큰을 발급합니다.
    • 이 액세스 토큰은 리소스 서버에 리소스에 대한 접근을 요청할 때 사용됩니다.
  5. 리소스 요청 (Resource Request):
    • 클라이언트는 액세스 토큰을 이용하여 리소스 서버에 접근을 요청합니다.
  6. 리소스 응답 (Resource Response):
    • 리소스 서버는 액세스 토큰의 유효성을 검사하고, 유효하다면 해당 리소스에 대한 응답을 클라이언트에게 반환합니다.

OAuth 2.0에는 이 외에도 "비밀번호 자격증명", "클라이언트 자격증명", "암시적" 등의 다양한 흐름이 있습니다. 위의 절차는 "권한 부여 코드" 흐름을 기반으로 설명한 것입니다. 사용하는 애플리케이션의 종류나 요구 사항에 따라 적합한 흐름을 선택하는 것이 중요합니다.

리소스 요청전까지 요청 작업이 2~3회 있는 이유(권한 요청과 토큰 요청으로 분리한 이유)

OAuth 2.0의 "권한 부여 코드" 흐름에서는 실제 리소스에 접근하기 전에 몇 단계의 요청과 인증 과정을 거칩니다. 이러한 다단계 접근 방식은 보안과 사용자의 데이터 프라이버시를 보호하기 위한 설계입니다.

요약하면 다음과 같습니다:

  1. 권한 요청: 초기 단계에서 사용자는 자신의 정보에 접근하도록 애플리케이션에 권한을 부여할 것인지 결정합니다. 이 과정은 권한 서버에서 처리되며, 사용자는 별도의 로그인 화면에서 인증을 진행하게 됩니다.
  2. 권한 부여: 사용자가 애플리케이션의 접근을 허용하면, 권한 서버는 애플리케이션(클라이언트)에게 권한 부여 코드를 전달합니다. 이 코드는 잠깐동안만 유효하며, 직접적으로 리소스에 접근하는데 사용되지 않습니다.
  3. 토큰 요청: 클라이언트는 권한 부여 코드와 자신의 인증 정보를 포함하여 권한 서버에 액세스 토큰을 요청합니다.
  4. 토큰 발급: 권한 서버는 클라이언트의 요청을 검증하고, 문제가 없다면 액세스 토큰을 발급합니다. 이 토큰을 사용하여 클라이언트는 리소스 서버에 접근할 수 있게 됩니다.

따라서, 실제로는 사용자의 데이터에 접근하기 전에 여러 번의 요청과 인증 과정을 거쳐야 합니다. 이는 보안을 강화하며, 사용자의 권한 부여 과정을 명확하게 하는데 중요한 역할을 합니다.

Q. 권한 요청할 때 이미 사용자 인증을 받았을 것으로 생각되는데 토큰 요청 부분을 추가적으로 넣어둔 이유로는 세션유지를 하기 위해서 서버 부담을 덜기 위해서 넣어둔 부분으로 보이네. 더욱 편리하기도 하고 ㅎ

맞습니다. OAuth 2.0의 "권한 부여 코드" 흐름은 여러 단계를 거치는데, 이는 몇 가지 기술적·보안적 이유로 인해 설계되었습니다.

  1. 분리된 권한 요청과 토큰 요청: 사용자 인증과 클라이언트 애플리케이션에 대한 토큰 발급은 별도의 단계로 분리되어 있습니다. 이렇게 함으로써, 권한 부여 코드는 짧은 생명주기를 갖게 되어 토큰이 노출될 위험을 줄입니다.
  2. 서버 부담 감소: 세션 기반의 인증 방식에서는 사용자의 모든 세션 상태를 서버에서 유지해야 합니다. 반면, 토큰 기반의 인증 방식에서는 이러한 상태 정보를 클라이언트에 저장할 수 있으므로 서버의 부담이 줄어듭니다.
  3. 스케일 아웃: 토큰 기반 인증은 서버의 확장성을 높이는데 도움을 줍니다. 각 서버는 토큰의 유효성만 검증하면 되므로, 사용자 세션 정보를 동기화할 필요가 없습니다.
  4. 플랫폼 간 호환성: 토큰은 다양한 플랫폼과 기기에서 사용될 수 있습니다. 예를 들어, 모바일 애플리케이션, 웹 애플리케이션, 다른 백엔드 서비스 등에서 동일한 토큰을 사용하여 인증할 수 있습니다.
  5. 제3의 애플리케이션 접근 제한: 사용자는 제3의 애플리케이션에 특정 리소스에만 접근을 허용할 수 있습니다. 이는 토큰의 권한 범위(scope)를 통해 제어됩니다.

이러한 이유들로 인해, OAuth 2.0은 많은 웹 서비스와 애플리케이션에서 선호되는 인증 방식 중 하나가 되었습니다.

권한 부여 코드가 유지시간이 짧기 때문에 보안상 유리한 이유

Q: 권한 부여 코드는 권한 요청 후 대부분 즉시 서버 측에서 다음 단계인 토큰 요청 단계로 넘어가기때문에 그렇게 길 필요가 없기 떄문에 그렇게 되어 있는 거지? 그래서 코드를 유실해 버려도 보안상 유리한 점이 있는 거고

정확합니다. 권한 부여 코드 흐름에서 권한 부여 코드는 일회용이며 짧은 생명주기를 가집니다. 그렇게 설계된 이유는 몇 가지 주요한 점을 기반으로 합니다.

  1. 일회성: 권한 부여 코드는 한 번만 사용됩니다. 클라이언트가 권한 서버로부터 권한 부여 코드를 받으면, 그 다음 단계에서는 이 코드를 사용하여 액세스 토큰을 요청합니다. 이 코드가 사용된 후에는 더 이상 유효하지 않으므로, 재사용이나 미사용에 대한 위험이 없습니다.
  2. 짧은 생명주기: 권한 부여 코드의 생명주기는 짧습니다. 이로 인해, 만약 코드가 타인에게 노출된다 해도 그 위험성은 제한적입니다. 코드가 빠른 시간 내에 사용되지 않으면 만료되기 때문입니다.
  3. 보안 강화: 권한 부여 코드 자체로는 사용자의 리소스에 접근할 수 없습니다. 이 코드는 단순히 다음 단계의 인증에 사용되기 때문입니다. 따라서, 이 코드가 노출되더라도 액세스 토큰을 얻기 위해서는 추가적인 클라이언트 정보가 필요합니다.

이러한 특성 덕분에, 권한 부여 코드는 OAuth 2.0의 보안을 강화하는 중요한 요소 중 하나입니다. 만약 코드가 유실되거나 타인에게 노출된다 해도, 그 자체로는 큰 위험을 초래하지 않으며, 더욱더 보안 조치를 강화할 수 있습니다.

OAuth 2.0 주요 용어

  1. 리소스 소유자(Resource Owner): 리소스에 대한 액세스 권한을 부여할 수 있는 주체, 주로 서비스의 최종 사용자입니다.
  2. 리소스 서버(Resource Server): 리소스 소유자의 정보를 호스팅하며 보호하는 서버로, 클라이언트가 액세스 토큰을 이용해 접근합니다.
  3. 클라이언트(Client): 리소스 소유자의 리소스에 액세스하는 애플리케이션입니다. 이는 웹 애플리케이션, 데스크톱 애플리케이션, 모바일 애플리케이션, 기타 임베디드 시스템 등이 될 수 있습니다.
  4. 인증 서버(Authorization Server): 리소스 소유자에게 클라이언트를 대신하여 리소스에 액세스하는 권한을 받는 과정에서 인증과 권한 부여를 담당하며, 이 과정 후에 액세스 토큰을 발급합니다.
  5. 액세스 토큰(Access Token): 클라이언트가 리소스 서버에 접근하기 위해 사용하는 자격 증명입니다. 이 토큰은 제한된 시간 동안만 유효합니다.
  6. 권한 부여 코드(Authorization Code): 클라이언트가 리소스 소유자로부터 권한을 받은 후, 인증 서버에게 액세스 토큰을 요청할 때 사용하는 일시적인 코드입니다.
  7. 리다이렉트 URI(Redirect URI): 권한 부여 코드나 액세스 토큰이 리턴되는 클라이언트의 URI입니다.
  8. 범위(Scope): 클라이언트가 요청하는 권한의 범위나 종류를 정의합니다. 예를 들면, 사용자의 프로필 정보 읽기, 이메일 읽기, 연락처 쓰기 등의 작업에 대한 권한을 범위로 지정할 수 있습니다.

이러한 용어들은 OAuth 2.0 프로토콜 내에서 정의되어 있으며, 각 요소는 인증과 권한 부여 프로세스 중 특정 역할을 담당합니다.

OAuth 2.0의 4가지 역할

  1. 리소스 소유자(Resource Owner):
    • 정의: 리소스에 대한 액세스 권한을 가진 개체, 주로 사용자입니다.
    • 설명: 예를 들어, 소셜 미디어 플랫폼에서 사용자는 자신의 프로필, 사진, 글 등의 리소스에 대한 액세스 권한을 가집니다. OAuth를 통해 외부 애플리케이션에 이러한 정보에 대한 접근 권한을 부여하거나 거부할 수 있습니다.
  2. 리소스 서버(Resource Server):
    • 정의: 리소스 소유자의 데이터를 보관하고 있는 서버로, 클라이언트의 요청을 처리하기 전에 액세스 토큰을 검증합니다.
    • 설명: 소셜 미디어 플랫폼에서의 사진, 글 등의 리소스가 저장되어 있는 서버를 의미합니다.
  3. 클라이언트(Client):
    • 정의: 리소스에 액세스하려는 애플리케이션. 리소스 소유자의 동의를 받아 인증 서버에서 액세스 토큰을 받아와 리소스 서버에 접근합니다.
    • 설명: 사용자가 로그인 기능이나 데이터 공유 기능을 통해 외부 애플리케이션(예: 모바일 앱, 웹 사이트)과 연동할 때 해당 애플리케이션이 클라이언트 역할을 합니다.
  4. 인증 서버(Authorization Server):
    • 정의: 클라이언트의 리소스 접근 요청을 인증하고 권한 부여를 담당하는 서버로, 권한 부여 성공 시 액세스 토큰을 발급합니다.
    • 설명: 이 서버는 리소스 소유자의 신원을 확인하고, 리소스 접근 권한을 부여받은 클라이언트에게 액세스 토큰을 발급하는 역할을 합니다.

이 네 가지 역할은 OAuth 2.0의 권한 부여 및 인증 프로세스에서 핵심적인 역할을 하며, 그들 간의 상호작용을 통해 안전하게 리소스에 대한 액세스를 관리합니다.

인증 서버와 리소스 서버가 분리되어 있는 이유

  1. 보안 강화: 인증 서버는 액세스 토큰 및 권한 부여 코드와 같은 중요한 자격 증명을 처리합니다. 이 서버와 리소스 서버를 분리함으로써, 각 서버에 대한 공격 범위를 제한하고, 하나의 서버에 보안 문제가 발생하더라도 다른 서버에 영향을 최소화 할 수 있습니다.
  2. 유연성: 다양한 리소스 서버들이 하나의 공통된 인증 서버를 사용할 수 있습니다. 이렇게 함으로써, 여러 서비스나 애플리케이션에 걸쳐 일관된 인증 방식을 제공할 수 있습니다.
  3. 확장성: 인증과 리소스 제공은 서로 다른 작업입니다. 각각의 서버를 분리함으로써, 각 서버의 확장 및 유지 보수를 독립적으로 진행할 수 있습니다.
  4. 재사용성: 특정 인증 방식을 사용하는 다양한 애플리케이션들이 동일한 인증 서버를 공유할 수 있습니다. 이로써 중복된 인증 구조의 개발 및 관리 비용을 절감할 수 있습니다.
  5. 최적화: 인증 서버는 사용자 인증, 토큰 발급 등의 작업에 특화되어 있습니다. 반면 리소스 서버는 데이터의 저장 및 제공에 중점을 둡니다. 각각의 서버를 분리함으로써, 서버의 역할에 따라 최적화된 성능 및 운영을 달성할 수 있습니다.

이와 같은 이유로, 많은 대규모 시스템 및 클라우드 기반 인프라에서는 인증 서버와 리소스 서버를 별도로 운영하는 것이 일반적입니다.

주로 사용하는 권한 부여 방식 2가지

OAuth 2.0에는 사실 네 가지 기본적인 권한 부여 방식(Grant Types)이 있습니다. 하지만 주로 사용되는 두 가지 권한 부여 방식에 초점을 맞춰 설명하겠습니다.

  1. 권한 부여 코드 방식(Authorization Code Grant)
    • 설명: 이 방식은 리다이렉션을 통해 사용자를 인증 서버로 이동시키며, 사용자는 그곳에서 권한을 부여합니다. 권한 부여 후, 사용자는 클라이언트로 리다이렉트되며, 이 때 권한 부여 코드가 클라이언트에게 전달됩니다. 클라이언트는 이 코드를 사용하여 인증 서버로부터 액세스 토큰을 요청합니다.
    • 장점: 중간자 공격(man-in-the-middle attack)에 대한 보안이 강화되어 있습니다. 실제 액세스 토큰은 클라이언트와 인증 서버 간의 안전한 통신을 통해서만 전달됩니다.
    • 적합한 사용 사례: 웹 서버와 같이 액세스 토큰을 안전하게 저장할 수 있는 서버 측 애플리케이션에서 주로 사용됩니다.
    • 느낌점(생각한 점)
      • 권한 부여 코드 방식이랑 s3의 signed url이랑 착각해서 거의 비슷한 거라 생각했는데
      • 알아보니 다른 거라고 한다.
      • 하나는 권한 부여 코드로 토큰 획득해서 그걸로 권한을 획득하는 방법이고(인증) 다른 하나는 그 승인된 url자체가 권한 부여된 거라고 보고 동작되는 방식이였다.
        • 권한 부여 코드 방식:
          • 이 방식은 사용자의 동의를 얻고, 그 동의를 기반으로 한 인증 절차를 거쳐서 액세스 토큰을 발급받는 방법입니다.
          • 받은 액세스 토큰을 사용하여 특정 리소스에 접근할 수 있게 됩니다.
          • 이 방식은 OAuth 2.0 인증 프로토콜의 일부로, 다양한 서비스와 플랫폼에서 사용자의 데이터를 안전하게 공유하기 위해 고안되었습니다.
        • AWS S3의 서명된 URL:
          • 서명된 URL은 특정 리소스에 대한 일시적인 접근 권한을 부여하기 위해 생성됩니다.
          • 이 URL은 서명되어 있으므로, 서명의 유효 기간 동안에만 해당 리소스(예: S3 객체)에 접근이 가능합니다.
          • 이 방식은 AWS의 자원에 일시적으로 접근 권한을 제공하고 싶을 때 사용됩니다, 예를 들면, 사용자에게 한시적으로 파일 다운로드 권한을 부여하거나, 외부에서 파일 업로드를 허용할 때 유용합니다.
  2. 암시적 부여 방식(Implicit Grant)
    • 설명: 이 방식은 권한 부여 코드를 사용하지 않고, 사용자가 권한을 부여한 후 바로 액세스 토큰을 클라이언트에게 전달합니다. 리다이렉션 URI를 통해 클라이언트로 액세스 토큰이 전달되는데, 이 URI의 프래그먼트에 토큰이 포함되어 있습니다.
    • 장점: 서버 측의 상호 작용이 없이도 클라이언트가 바로 토큰을 받을 수 있으므로 간결하고 빠릅니다.
    • 적합한 사용 사례: JavaScript와 같은 클라이언트 측 언어로 작성된 단일 페이지 애플리케이션(SPA) 등에서 주로 사용됩니다.
  3. 리소스 소유자 암호 자격 증명 방식 (Resource Owner Password Credentials Grant)
    • 이 방식은 사용자의 ID와 비밀번호를 직접 사용하여 액세스 토큰을 얻는 방식입니다.
    • 사용자의 인증 정보(ID/비밀번호)를 직접 클라이언트에 입력하면, 클라이언트는 이를 사용하여 토큰을 요청합니다.
    • 이 방식은 신뢰도가 매우 높은 클라이언트에 한해서 사용됩니다. 예를 들면, 사용자와 동일한 조직 내에서 개발된 클라이언트가 이에 해당합니다.
    • 보안적으로 권장되지 않는 방식이지만, 기존의 시스템이 사용자 이름과 비밀번호를 이용한 방식으로 구현되어 있을 때 OAuth 2.0으로의 부드러운 전환을 위해 사용되기도 합니다.
  4. 클라이언트 자격 증명 방식 (Client Credentials Grant)
    • 이 방식은 애플리케이션 자체의 자격 증명을 사용하여 액세스 토큰을 얻는 방식입니다.
    • 주로 백엔드 서버간 통신 시 사용됩니다. 즉, 특정 사용자의 자격 증명이 없이도 토큰을 발급받아야 할 때 사용되는 방식입니다.
    • 예를 들면, 한 서버가 다른 서버의 API를 사용하여 일반 정보(특정 사용자와 무관한)를 가져오는 경우에 사용될 수 있습니다.
    • 클라이언트 인증만으로 토큰이 발급되기 때문에, 이 토큰으로의 접근은 매우 제한적인 권한을 가지게 됩니다.

각 방식은 특정한 사용 사례에 최적화되어 있습니다. 따라서 애플리케이션의 요구 사항과 환경에 따라 적절한 승인 방식을 선택하는 것이 중요합니다.

  • 예시
    • 실 사용 예시:
      1. 사용자가 웹 기반 음악 스트리밍 서비스에 로그인하려고 합니다.
      2. 서비스는 사용자의 프로필 정보와 재생 목록을 표시하기 위해 특정 소셜 미디어 플랫폼(예: Facebook)의 API에 접근할 권한을 필요로 합니다.
      3. 사용자는 음악 스트리밍 서비스에 로그인 버튼을 클릭합니다.
      4. 사용자는 소셜 미디어 플랫폼의 로그인 페이지로 리디렉션됩니다.
      5. 사용자가 소셜 미디어 플랫폼에 로그인하고 음악 스트리밍 서비스에 필요한 권한을 부여하면, 서비스는 액세스 토큰을 즉시 반환받게 됩니다.
      6. 반환받은 액세스 토큰은 URL의 Fragment Identifier(#) 부분에 포함되어 있습니다. 자바스크립트를 사용하여 이 토큰을 추출하고 API 요청에 사용할 수 있습니다.
    • 주의할 점:
      • 암시적 부여 방식은 단순화된 접근 방식이기 때문에 보안상의 문제점이 있을 수 있습니다. 토큰이 URL에 포함되기 때문에, 브라우저의 히스토리나 로그 등에서 노출될 위험이 있습니다. 따라서 이 방식은 토큰의 유효 기간이 짧은 경우나 고위험 데이터에 대한 접근 권한이 필요하지 않은 경우에 주로 사용됩니다.
      • 최근에는 암시적 부여 방식 대신 PKCE(Proof Key for Code Exchange) 확장을 사용한 권한 부여 코드 방식이 클라이언트 사이드 어플리케이션에서 권장되고 있습니다. PKCE는 보안을 강화하기 위한 추가적인 단계를 포함하며, 특히 모바일 앱과 같은 네이티브 클라이언트에서 사용됩니다.
        • Q.
          • 암시적 부여 방식은 get방식에 토큰값을 넣은 것 아니야? 너무 위험한데 그것보다 get방식 자체가 위험성이 좀 있어
          • 맞습니다. 암시적 부여 방식은 액세스 토큰을 URL의 Fragment Identifier(#) 부분에 직접 포함시키는 방식으로 동작합니다. 이는 주로 GET 요청을 통해 클라이언트에게 리디렉션됩니다.
          • 암시적 부여 방식이 주는 위험성 중 하나는 바로 이 점 때문입니다. GET 요청의 URL은 다양한 곳에서 기록될 수 있습니다. 예를 들면, 브라우저의 히스토리, 서버 로그, 웹 애플리케이션 방화벽, 캐시 등 다양한 곳에 URL이 저장되거나 기록될 수 있습니다. 이렇게 되면 액세스 토큰이 노출되는 위험이 커지게 됩니다.
          • 또한 GET 요청은 일반적으로 데이터를 전송하는 용도가 아닌, 데이터를 조회하는 용도로 사용되는 HTTP 메서드입니다. 이런 이유로 보안상 중요한 데이터를 포함시켜 전송하는 것은 좋은 방법이 아닙니다.
          • 암시적 부여 방식의 도입 초기에는 클라이언트 사이드 웹 애플리케이션에서 서버와의 중간 단계를 줄이려는 의도로 도입되었습니다. 하지만 위에서 언급한 보안 문제로 인해, 현대의 많은 보안 전문가나 권장 가이드라인에서는 이 방식을 피하도록 권장하고 있습니다.
          • 최근에는 PKCE(Proof Key for Code Exchange)와 같은 확장된 방식을 사용하여 보안을 강화하는 추세입니다. 이를 통해 클라이언트 사이드 애플리케이션에서도 보안성이 높은 OAuth 2.0 인증을 구현할 수 있게 되었습니다.

이외에도 "리소스 소유자 암호 자격 증명(Resource Owner Password Credentials)" 방식과 "클라이언트 자격 증명(Client Credentials)" 방식이 있습니다. 각 방식은 특정 시나리오와 환경에 따라 사용됩니다. 사용 환경과 보안 요구 사항에 따라 적절한 권한 부여 방식을 선택하는 것이 중요합니다.

4가지 승인 방식 중 나머지 2가지 방식

OAuth 2.0은 다양한 애플리케이션 유형에 적합하도록 4가지 승인 방식을 제공합니다. 앞서 설명드린 '권한 부여 코드 방식'과 '암시적 부여 방식'에 이어, 나머지 두 방식인 '리소스 소유자 암호 자격 증명 방식'과 '클라이언트 자격 증명 방식'에 대해 설명하겠습니다.

  1. 리소스 소유자 암호 자격 증명 방식 (Resource Owner Password Credentials Grant)
    • 이 방식은 사용자의 ID와 비밀번호를 직접 사용하여 액세스 토큰을 얻는 방식입니다.
    • 사용자의 인증 정보(ID/비밀번호)를 직접 클라이언트에 입력하면, 클라이언트는 이를 사용하여 토큰을 요청합니다.
    • 이 방식은 신뢰도가 매우 높은 클라이언트에 한해서 사용됩니다. 예를 들면, 사용자와 동일한 조직 내에서 개발된 클라이언트가 이에 해당합니다.
    • 보안적으로 권장되지 않는 방식이지만, 기존의 시스템이 사용자 이름과 비밀번호를 이용한 방식으로 구현되어 있을 때 OAuth 2.0으로의 부드러운 전환을 위해 사용되기도 합니다.
  2. 클라이언트 자격 증명 방식 (Client Credentials Grant)
    • 이 방식은 애플리케이션 자체의 자격 증명을 사용하여 액세스 토큰을 얻는 방식입니다.
    • 주로 백엔드 서버간 통신 시 사용됩니다. 즉, 특정 사용자의 자격 증명이 없이도 토큰을 발급받아야 할 때 사용되는 방식입니다.
    • 예를 들면, 한 서버가 다른 서버의 API를 사용하여 일반 정보(특정 사용자와 무관한)를 가져오는 경우에 사용될 수 있습니다.
    • 클라이언트 인증만으로 토큰이 발급되기 때문에, 이 토큰으로의 접근은 매우 제한적인 권한을 가지게 됩니다.

각 방식은 특정한 사용 사례에 최적화되어 있습니다. 따라서 애플리케이션의 요구 사항과 환경에 따라 적절한 승인 방식을 선택하는 것이 중요합니다.