OAuth2

OAuth는 리소스 소유자(사용자)가 자신의 자격 증명을 공유하지 않고도, 클라이언트(앱)가 리소스 서버(API)에 제한된 권한으로 접근할 수 있도록 허용하는 권한 부여 프로토콜입니다.
이 과정은 보안을 강화하고, 사용자의 민감한 정보(비밀번호 등)가 유출되지 않도록 돕습니다.

OAuth 흐름의 주요 단계 (Authorization Code Grant 방식 기준)

• 클라이언트 애플리케이션 요청
  클라이언트(앱)는 사용자가 인증 및 권한 승인을 위해 Authorization Server에 리다이렉트됩니다.

사용자에게 권한 승인을 요청하는 화면이 표시됩니다.

• 사용자 승인 (Authentication)
  사용자는 자신의 계정을 이용해 로그인하고, 클라이언트가 요청하는 권한을 승인합니다.

• Authorization Code 발급
  권한을 승인받으면, Authorization Server는 클라이언트에게 Authorization Code를 발급합니다.
  이 코드는 클라이언트가 액세스 토큰을 요청할 때 사용됩니다.

• Access Token 발급
  클라이언트는 Authorization Code를 사용해 Access Token을 요청합니다.
  Authorization Server는 클라이언트의 신원을 확인하고, Access Token을 발급합니다.

• 리소스 서버 접근
  클라이언트는 발급받은 Access Token을 사용해 Resource Server에 요청을 보냅니다.

Resource Server는 토큰을 확인하고, 권한이 유효하면 요청된 데이터를 반환합니다.

주요 요소의 역할

• Authorization Server (권한 서버)

사용자의 신원을 확인하고, 클라이언트에게 Authorization Code와 Access Token을 발급합니다.
예: Google OAuth 서버

• Resource Server (리소스 서버)

Access Token을 검증하고, 사용자의 데이터나 리소스를 제공합니다.
예: Google의 사용자 정보 API

• Client (클라이언트 애플리케이션)

사용자의 승인을 받아 Access Token을 요청하고, 리소스 서버에서 데이터를 가져옵니다.
예: 사용자가 로그인하는 웹 애플리케이션 또는 모바일 앱

• Resource Owner (리소스 소유자)

리소스의 실제 소유자, 즉 사용자입니다.
예: Google 계정을 가진 사용자

예제 흐름

사용자가 클라이언트 애플리케이션에 로그인 버튼을 클릭합니다.

1. 브라우저가 Authorization Server(예: Google 로그인 페이지)로 리다이렉트됩니다.

2. 사용자는 Google 계정으로 로그인하고, 앱이 요청하는 권한(프로필, 이메일 등)을 승인합니다.

3. 권한 승인 후, Authorization Server는 클라이언트 애플리케이션으로 Authorization Code를 반환합니다.

4. 클라이언트 애플리케이션은 Authorization Code를 사용해 Authorization Server로 Access Token을 요청합니다.

5. Access Token을 받은 클라이언트는 이를 사용해 Resource Server에서 사용자 데이터를 요청합니다.
   예: Google 사용자 정보 API 호출.

6. 리소스 서버는 Access Token을 검증하고, 권한이 유효하면 요청된 데이터를 반환합니다.

시나리오 요약 (Google OAuth 예시)

사용자: "구글 계정으로 로그인" 클릭 → 로그인 후 권한 승인.
Authorization Server(Google): 클라이언트에게 Authorization Code 전달.
클라이언트(앱): Authorization Code로 Access Token 요청.
Authorization Server(Google): Access Token 발급.
클라이언트(앱): Access Token으로 사용자 정보를 요청.
Resource Server(Google): 사용자 데이터 반환.

이 과정은 클라이언트와 리소스 소유자(사용자) 간의 신뢰성을 보장하며, 민감한 정보를 직접 공유하지 않고 안전하게 리소스를 접근할 수 있도록 설계되었습니다.

OAuth vs OAuth2

OAuth (OAuth 1.0a)

• 출시 시기: 2007년에 발표된 초기 버전입니다.

• 인증 방식: HMAC-SHA1 또는 RSA-SHA1 기반의 서명(signature)을 사용하여 요청을 인증합니다.
  요청 서명에는 클라이언트와 서버 간에 미리 공유된 비밀 키(shared secret)를 필요로 합니다.

• 보안: 요청 서명 방식은 보안성이 있지만, 구현이 복잡하고 오류가 발생하기 쉽습니다.
  모든 요청에 대해 서명을 생성해야 하며, 이는 클라이언트 개발자의 부담을 증가시킵니다.
  HTTPS가 필수는 아니지만 권장됩니다.

• 사용자 경험: 사용자 인증을 위해 번거로운 절차를 요구하는 경우가 많으며, 모바일 및 웹 환경에서 다소 불편할 수 있습니다.

• 제한 사항:Access Token과 Request Token을 혼합적으로 사용하며, API 요청마다 서명을 포함해야 해서 복잡합니다.

OAuth 2.0

• 출시 시기: 2012년에 발표된 OAuth의 개선된 버전입니다.
• 인증 방식: OAuth2는 Bearer Token을 사용하여 요청을 인증합니다.
  Bearer Token은 간단히 요청 헤더에 포함되어 전달됩니다:

Authorization: Bearer <access_token>

요청 서명이 필요하지 않아 구현이 훨씬 간단합니다.

• 보안: HTTPS가 필수로 요구됩니다.
  보안이 HTTPS에 크게 의존하므로 네트워크 레벨의 보안이 중요합니다.
  Refresh Token을 지원하여 Access Token 만료 시 재발급이 가능.

• 유연성: 다양한 인증 흐름(Grant Type)을 지원합니다:

  • Authorization Code Grant: 서버 측 애플리케이션에 적합.
  • Implicit Grant: 클라이언트 측 애플리케이션(주로 SPA)에 적합. (현재는 보안 문제로 잘 사용되지 않음)
  • Resource Owner Password Credentials Grant: 제한적으로 사용.
  • Client Credentials Grant: 서버 간 통신에 적합.

• 사용자 경험: OAuth 2.0은 주로 웹과 모바일 환경에 적합하도록 설계되어 사용자 인증 절차가 간소화되었습니다.

• 구조적인 차이: OAuth 2.0은 JSON 기반으로 데이터를 주고받아 읽기 쉽고, RESTful API와 잘 통합됩니다.
  OAuth 1.0의 복잡한 요청 서명 방식 대신 토큰 중심 인증 방식을 사용해 간단합니다.