OAuth2

🔔 Oauth2? 그럼 Oauth1도?
🔔 Oauth2 동작 과정

RFC6749(Oauth 2.0) 문서를 토대로 요약하여 정리한 글이니, 자세한 내용은 해당 문서를 참고해주시기 바랍니다.

What? Why?

인증(authentication)이 아닌 인가(authorization)에 초점을 맞추며, 리소스 소유자가 클라이언트에게 자신의 리소스에 대한 제한적 접근 권한을 부여할 수 있도록 하는 프레임워크

역할

• Resource Owner
  • 보호된 리소스(Protected Resource)의 실제 소유자 혹은 주체
  • ex) 사용자의 계정, 사용자 데이터
• Resource Server
  • 보호된 리소스를 호스팅(저장 및 관리)하고 있는 서버
  • 클라이언트가 제공하는 액세스 토큰을 검증하고, 유효한 토큰이면 리소스 접근을 허용
• Client
  • 리소스 소유자를 대신하여 리소스에 접근하려고 요청하는 애플리케이션
  • ex) 웹 애플리케이션, 모바일 앱, 데스크톱 프로그램 등
• Authorization Server
  • 클라이언트의 권한 요청을 인증/인가하고, 액세스 토큰(혹은 리프레시 토큰)을 발급하는 서버
  • Resource Owner와 Client 사이에서 안전하게 토큰을 주고받도록 중재

Oauth 1.0 vs 2.0

기존 Oauth 1.0은 다음과 같은 문제점이 있었는데, 이를 개선하기 위해 Oauth 2.0이 만들어졌다.

1.0

• 복잡한 서명 프로세스
  • 각 요청마다 서명을 생성
• 유연성 부족
  • 특정한 인증 플로우에 국한되어 있음
  • ex) 모바일 앱, 단일 페이지 애플리케이션(SPA) 등
• 보안상의 제약
  • HTTPS와 같은 전송 계층 보안을 완전히 대체할 수 없음
  • 서명 관리 자체가 보안 위험 요소 가능성
• 확장성의 한계

2.0

• 단순화된 인증 프로세스
  • 서명 기반 인증을 제거하고 HTTPS를 기본 보안 계층으로 사용
• 다양한 인증 플로우 지원
  • 다양한 인증 플로우(그랜트 타입)를 지원
  • ex) Authorization Code, Implicit, Client Credentials 등
• 확장성과 유연성 향상
  • 모듈식 아키텍처를 채택하여 필요에 따라 확장 가능
  • ex) PKCE(Proof Key for Code Exchange)
• 향상된 보안 기능
  • 토큰 기반 인증
  • 토큰의 범위(scope) 세분화
• 더 나은 사용자 경험
  • SPA나 네이티브 모바일 애플리케이션에서도 쉽게 통합 가능

흐름도

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

(A) 클라이언트가 승인 요청

클라이언트는 리소스 소유자에게 직접 승인 요청을 할 수 있다. 인증 요청은 리소스 소유자 직접 이루어질 수도 있고 중개자로서 인증 서버를 통해 간접적으로 이루어질 수도 있다.

(B) 인증 부여를 받음

클라이언트는 리소스 소유자의 인증을 나타내는 자격 증명인 인증 부여를 받는다. 명세서에 정의된 네 가지 유형 중 하나를 사용하거나 확장 부여 유형을 사용하여 표현된다. 인증 부여 유형은 클라이언트가 인증을 요청하는 데 사용하는 방법과 인증 서버가 지원하는 유형에 따라 다르다.

(C) 엑세스 토큰 요청

클라이언트는 권한 부여 서버로 인증하고 권한 부여를 제시하여 액세스 토큰을 요청한다.

(D) 엑세스 토큰 발급

인증 서버는 클라이언트를 인증하고 인증 부여를 검증한 후에, 유효한 경우 액세스 토큰을 발급한다.

(E) 인증

클라이언트는 리소스 서버에서 보호되는 리소스를 요청하고 액세스 토큰을 제시하여 인증한다.

(F) 요청 처리

리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우, 요청을 처리한다.

다음 장에 이어서..

자료 출처

RFC 6749
ChatGPT