[F-Lab 모각코 챌린지 22일차] OAuth 프로토콜 (1)

Nami·2023년 6월 22일
0

66일 포스팅 챌린지

목록 보기
22/66
post-custom-banner

OAuth(Open Authorization)

OAuth는 구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization) 받을 수 있는 표준 프로토콜 OAuth는 사용자의 비밀 정보를 제공하지 않고도 클라이언트 애플리케이션이 다른 서비스에 대한 제한적인 액세스 권한을 획득할 수 있는 방법을 제공한다.

주로 웹 및 모바일 애플리케이션에서 사용되며, 소셜 미디어 플랫폼 및 온라인 서비스에서 제공되는 API와의 통합에 자주 사용됨.

등장 배경

OAuth가 등장한 배경은 사용자가 한 서비스(클라이언트)의 인증 정보를 다른 서비스(서비스 제공자)와 공유하지 않으면서도 클라이언트가 다른 서비스의 리소스에 접근할 수 있는 방법이 필요하다는 요구에 기인한다.

💡 여러 은행 계좌에 액세스할 수 있는 앱을 발견했다고 가정해 보겠습니다. 앱이 세금 관련 업무를 처리하거나 예산을 관리하는 데 사용될 수도 있습니다. 앱으로 관리하려는 은행 계좌가 3개 있고 계좌마다 사용자 이름과 비밀번호가 다릅니다. 이제 앱에서 은행 계좌에 액세스하려면 민감한 사용자 인증 정보가 필요합니다. 기본적으로 이러한 민감한 정보를 앱에 제공합니다. 앱이 비밀번호 및 사용자 이름을 소유하는 것을 신뢰할 수 있나요? 앱이 해킹되면 어떻게 될까요? 이제 각 계정의 은행 사용자 인증 정보를 변경해야 한다는 점을 기억해야 합니다. 이는 OAuth 2.0이 해결하는 근본적인 문제입니다.

OAuth 2.0 주체

Client 클라이언트

  • Application
  • 휴대기기 또는 웹 앱에서 실행되는 앱.
  • Resource Server의 자원을 이용하고자 하는 서비스.
  • OAuth 인증을 필요로 하는 클라이언트 애플리케이션
  • 보통 우리가 개발하려는 서비스
  • 사용자가 액세스하려는 리소스 또는 서비스에 대한 인증을 요청하는 애플리케이션 또는 서비스
  • 애플리케이션은 인증을 위해 OAuth 프로토콜을 사용하여 서비스 제공자로부터 액세스 토큰을 얻는다.

Client는 우리가 구현하는 서비스이므로 Resource Owner와 헷갈리지 말자. Resource Server와 Authorization Server의 입장에서는 우리 서비스가 클라이언트이기 때문에 이런 이름을 갖게 된 것 이다.

Resource Owner 사용자

  • 리소스 소유자
  • 우리의 서비스를 이용하면서 구글, 페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자
  • 클라이언트 애플리케이션에 로그인하여 자원에 대한 액세스 권한을 부여
  • 리소스라 하면 '구글 캘린더 정보', '페이스북 친구 목록', '네이버 블로그 포스트 작성' 등이 해당

Authorization Server 서비스 제공자

  • Authoriztion Server는 Resource Owner를 인증하고, Client에게 액세스 토큰을 발급해주는 서버이다.
  • 인증 및 권한 부여를 관리하는 서버
  • 클라이언트 애플리케이션에 대한 인증을 수행하고, 액세스 토큰을 발급하여 리소스에 대한 접근 권한을 부여

Resource Server 자원 서버

  • 클라이언트 애플리케이션이 액세스하려는 자원이 있는 서버
  • 클라이언트 애플리케이션이 액세스하려는 보호된 리소스가 있는 서버
  • 구글, 페이스북, 트위터
  • 액세스 토큰의 유효성을 검증
  • 클라이언트 애플리케이션이 올바른 액세스 토큰을 제공했을 때만 자원에 대한 요청을 승인
  • 클라이언트에게 리소스에 대한 접근 권한을 부여 또는 거부

Authorization Server와 Resource Server는 공식문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지, 하나의 서버로 구성할지는 개발자가 선택하기 나름이라고 한다.

동작 과정

  1. 클라이언트 등록: 클라이언트(애플리케이션)는 서비스 제공자에게 등록을 요청하여 클라이언트 아이디와 클라이언트 비밀번호를 발급받음. 클라이언트는 인증 서버와 통신할 수 있는 신원을 갖게 됨.

  2. 액세스 할 수 있도록 사용자 인증 요청: 클라이언트는 사용자를 인증하기 위해 인증 서버에 사용자 인증 요청을 보냅니다. 이는 사용자가 액세스하려는 서비스의 인증 과정을 수행하기 위한 단계.

  3. 사용자 인증 및 권한 부여: 인증 서버는 사용자의 인증을 확인하고, 클라이언트에게 사용자 동의를 요청.

    앱이 최종 사용자로 인증하는 경우 OAuth 동의 화면을 표시하므로 사용자가 요청된 데이터에 대한 액세스 권한을 앱에 부여할지 결정

  4. 액세스 토큰 발급: 사용자가 액세스 권한을 부여하면, 인증 서버는 클라이언트에게 액세스 토큰을 발급합니다. 액세스 토큰은 클라이언트가 보호된 리소스에 접근할 때 사용됩니다.

  5. 리소스 서버 접근: 클라이언트는 발급받은 액세스 토큰을 사용하여 보호된 리소스 서버에 접근합니다. 이때, 클라이언트는 액세스 토큰을 요청에 첨부하고 리소스 서버에 접근 권한을 부여받습니다.

  6. 리소스 제공: 리소스 서버는 클라이언트의 액세스 토큰을 검증하고, 요청된 리소스를 제공합니다. 클라이언트는 리소스에 대한 작업을 수행하고 결과를 받아옵니다.

TCP/IP에 치중하여 OAuth 프로토콜은 공부량이 적은 것 같아 아쉽다. 내일 좀 더 보충할 예정.


참조 ✅

post-custom-banner

0개의 댓글