OAuth (Open Authorization)

 

OAuth (Open Authorization)

: 제3자 애플리케이션이 사용자의 자격 증명(예: 비밀번호) 없이 사용자의 리소스에 접근하도록 허용하는 인증 및 권한 부여 프레임워크입니다. OAuth는 특히 소셜 로그인, API 연동, 클라우드 서비스 통합 등에 널리 사용됩니다.

 

---

OAuth의 기본 개념

1. 클라이언트(Client):
   • 사용자의 리소스에 접근하려는 애플리케이션 (예: 타사 앱, 웹사이트).
2. 리소스 소유자(Resource Owner):
   • 리소스에 대한 접근 권한을 가진 사용자.
3. 리소스 서버(Resource Server):
   • 리소스를 호스팅하는 서버 (예: Google Drive, GitHub API).
4. 권한 서버(Authorization Server):
   • 리소스 서버와 분리된 서버로, 사용자의 인증을 처리하고 액세스 토큰을 발급.
5. 액세스 토큰(Access Token):
   • 클라이언트가 리소스 서버에 접근할 때 사용하는 임시 권한 증명.

---

OAuth의 주요 흐름

1. 사용자 권한 요청
   • 클라이언트가 리소스 소유자에게 권한을 요청.
   • 사용자는 권한 부여 여부를 결정.
2. 권한 코드 발급 (Authorization Code Grant)
   • 사용자가 권한을 승인하면, 클라이언트는 권한 서버로부터 **권한 코드(Authorization Code)**를 받음.
3. 액세스 토큰 발급
   • 클라이언트는 권한 코드를 권한 서버에 전송하여 액세스 토큰을 요청.
   • 권한 서버는 인증 후 액세스 토큰을 발급.
4. 리소스 요청
   • 클라이언트는 액세스 토큰을 사용하여 리소스 서버에 요청.
   • 리소스 서버는 토큰을 검증하고 요청을 처리.

---

OAuth 2.0의 권한 부여 방식

OAuth 2.0은 다양한 상황에 맞게 **4가지 권한 부여 방식(Grant Type)**을 제공합니다.

1. Authorization Code Grant
   • 사용 사례: 웹 애플리케이션.
   • 가장 보안성이 높은 방식으로, 클라이언트는 권한 코드를 통해 액세스 토큰을 발급받음.
   흐름:
   1. 사용자가 클라이언트 애플리케이션에서 로그인.
   2. 권한 서버에서 사용자 인증 및 권한 부여 코드 발급.
   3. 클라이언트는 권한 코드를 권한 서버로 보내고, 액세스 토큰을 발급받음.
2. Implicit Grant
   • 사용 사례: SPA(Single Page Application) 등 클라이언트 측에서만 실행되는 애플리케이션.
   • 액세스 토큰이 권한 코드 없이 브라우저에 직접 전달.
   단점: 보안에 취약(액세스 토큰이 브라우저에 노출).
3. Resource Owner Password Credentials Grant
   • 사용 사례: 신뢰할 수 있는 애플리케이션.
   • 사용자가 자신의 자격 증명(아이디와 비밀번호)을 직접 클라이언트에 입력하여 토큰 발급.
   단점: 사용자의 자격 증명이 클라이언트에 노출될 수 있음.
4. Client Credentials Grant
   • 사용 사례: 서버 간 통신(API 호출 등).
   • 사용자 인증 없이 클라이언트 애플리케이션 자체가 리소스에 접근.

---

OAuth와 OpenID Connect (OIDC)

OAuth는 권한 부여를 위한 프레임워크입니다.
OpenID Connect (OIDC)는 OAuth 2.0 위에 인증(Authentication) 기능을 추가한 프로토콜로, 사용자가 누구인지 확인하는 데 중점을 둡니다.

차이점

특징	OAuth 2.0	OpenID Connect
목적	권한 부여 (Authorization)	인증(Authentication)
결과물	액세스 토큰(Access Token)	ID 토큰(ID Token)
사용 사례	API 호출, 리소스 접근	로그인 및 사용자 식별

 

---

OAuth의 장점

1. 보안성:
   • 사용자 비밀번호를 타사 애플리케이션에 노출하지 않고 인증 및 권한 부여 가능.
2. 유연성:
   • 다양한 애플리케이션 환경(웹, 모바일, 서버 간 통신 등)에 적용 가능.
3. 확장성:
   • 여러 서비스 간에 권한 부여를 표준화하여 확장 가능.
4. 사용자 편의:
   • 소셜 로그인(예: Google, Facebook) 등을 통해 사용자 경험 개선.

---

OAuth의 단점

1. 구현 복잡성:
   • 인증 흐름과 보안을 올바르게 설계하는 데 많은 노력 필요.
2. 액세스 토큰 유출 가능성:
   • 토큰 유출 시 악의적인 사용자가 리소스에 접근할 수 있음.
3. 권한 부여 서버 의존성:
   • 권한 서버가 작동하지 않으면 전체 인증 시스템에 문제가 발생할 수 있음.

---

OAuth 사용 사례

1. 소셜 로그인
   • 사용자는 Google, Facebook 등의 계정을 통해 로그인.
   • 클라이언트 애플리케이션은 사용자의 리소스에 접근.
2. API 통합
   • 외부 서비스(GitHub, Stripe 등)와 애플리케이션 간의 데이터 교환.
3. 클라우드 서비스
   • 한 서비스에서 다른 서비스로 파일 업로드(Google Drive → Dropbox).
4. 모바일 애플리케이션
   • 사용자가 앱에서 리소스에 접근하도록 인증 및 권한 부여.

---

OAuth 보안 팁

1. HTTPS 사용
   • 데이터 전송 중 도청 방지.
2. 짧은 액세스 토큰 수명
   • 액세스 토큰이 짧게 유지되도록 설정하여 유출 시 피해를 최소화.
3. 리프레시 토큰 사용
   • 액세스 토큰이 만료되면 리프레시 토큰으로 새 토큰 발급.
4. 범위(Scope) 제한
   • 토큰이 특정 작업이나 리소스에만 접근할 수 있도록 범위를 제한.
5. PKCE(Proof Key for Code Exchange)
   • SPA와 같은 클라이언트에서 권한 코드가 도난당하는 것을 방지.

---

OAuth는 현대 웹과 모바일 애플리케이션의 인증 및 권한 부여의 표준으로 자리 잡았습니다. 올바르게 설계하고 구현하면 보안성과 사용자 편의성을 모두 만족시킬 수 있습니다. 😊