OAuth

Intro

안녕하세요. 정예림 사원입니다.
OAuth의 정의와 OAuth1.0과 OAuth2.0를 비교하여 정리하였습니다.

OAuth

• OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대한 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준을 말합니다.

  OAuth의 배경

  간단하게 인증과 권한을 획득

• 일반적인 웹사이트의 서비스에 개인 정보를 주다는 것은 꽤 위험한 일입니다.
• 사용자도 사이트를 이용하기 껄그럽고, 사이트를 운영하는 운영자도 부담이 컸습니다.
• 이것을 해결하기 위해 OAuth가 탄생하게 되었습니다.
• 개인정보는 정말 안전한 큰 기업(naver, kakao, google 등)에 맡기고, 해당 기업에서 정보를 확인하고 접근할 수 있는 토큰만 발급해줍니다.
• 이렇게 되면 운영자의 부담이 덜게 되고, 사용자는 안전함과 동시에 편리함을 갖추게 됩니다.

  OAuth 1.0 용어

  

  OAuth 1.0 참여자

• Service provider : OAuth를 사용하는 Open API를 제공하는 서비스
• User : Service Provider에 계정을 가지고 있으면서, Consumer를 이용하려는 사용자
• Consumer : OAuth 인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스

  Token

• Request Token : Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 토큰.
  (인증이 완료된 후에는 Access Token으로 교환)
• Access Token : 인증 후 Consumer가 Service Provider의 자원에 접근하기 위해 키를 포함한 토큰.

OAuth 1.0 인증 과정

인증 과정

• Request Token의 요청과 발급 → 사용자 인증 페이지 호출 → 사용자 로그인 완료 → 사용자의 권한 요청 및 수락 → Access Token 발급 → Access Token을 이용해 서비스 정보 요청

• Access Token을 가지고 있는 Consumer는 사전에 호출이 허락된 Service Provider의 오픈 API를 호출

  oauth_signature 만들기

  권한을 준 행위가 이루어졌음을 프로그램을 통해 증명하는 방식으로 서명(Signature) 을 이용

• Request Token, Access Token 발급 요청시 토큰에 포함 되는 매개변수 oauth_signature
• HMAC 암호화 방법을 적용하여 oauth_signature가 생성되며 OAuth 1.0 인증에서 가장 까다로운 과정이다.

  OAuth 2.0

  OAuth 1.0 단점

  • 웹 애플리케이션이 아닌 애플리케이션에서는 사용이 곤란하다.
  • 절차가 복잡하여 OAuth 구현 라이브러리 제작이 어렵다.
  • 복잡한 절차로 Service Provider에게도 연산 부담이 발생한다.

OAuth 2.0 특징

• 웹어플리케이션이 아닌 애플리케이션 지원 강화
• 암호화가 필요 없음 (HTTPS를 사용하고 HMAC는 사용하지 않는다)
• OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정 가능
• 기능 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어짐
• 1.0a는 인증방식이 한가지 였지만 2.0는 다양한 인증방식을 지원

  OAuth 2.0 용어

  

OAuth 2.0 참여자

• Resurce Server(자원 서버) : OAuth2.0 서비스를 제공하고, 자원을 관리하는 서버
• Resurce Owner(자원 소유자) : Resource Server의 계정을 소유하고 있는 사용자
• Client : Resource Server의 API를 사용하여 데이터를 가져오려고 하는 사이트 (개발 사이트)
• Authorization Server(권한 서버) : Client가 Resource Server의 서비스를 사용할 수 있게 인증하고 토큰을 생성해주는 서버 (보통 gogle, naver 같은 사이트)

  Token

• Access Token : 자원 서버에 자원을 요청할 수 있는 토큰
• Refresh Token : 권한 서버에 접근 토큰을 요청할 수 있는 토큰

OAuth 2.0 인증 과정

OAuth2의 프로토콜 흐름

• (A) (앱 → 사용자) 사용자가 데이터에 접근하기 위해 권한을 요청
• (B) (사용자 → 앱) 접근에 동의함을 증명하는 권한 부여 동의서를 발급
• (C) (앱 → 권한 제공기관) 권한 부여 동의서를 제출
• (D) (권한 제공기관 → 앱) 권한 부여 동의서를 확인하여 접근 토큰을 제공
• (E) (앱 → 데이터 제공기관) 접근 토큰을 제출하여 사용자 데이터를 요청
• (F) (데이터 제공기관 → 앱) 사용자 데이터를 제공

  권한 부여 동의서 방식 4가지

• Autorization Code Grant(권한 부여 코드 승인) (PKCE)
  • Client가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용
  • 리소스 접근을 위해, Authorization Server에서 받은 권한 코드로 리소스에 대한 액세스 토큰을 받는 방식
  • 다른 인증 절차에 비해 보안성이 높기 때문에 주로 사용
• Implicit Grant(암묵적 승인)
  • Authorization Code Grant과 다르게 권한 코드 교환 단계가 없음
  • 엑세스 토큰을 즉시 반환받아 이를 인증에 사용하는 방식
• Resurce Owner Passward Credentials Grant(리소스 소유자 암호 자격 승인)
  • Client 암호를 사용하여 액세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식
  • Resurce Owner에서 ID, Password를 전달 받아 Resurce Server에 인증하는 방식으로 신뢰할 수 있는 Client인 경우 가능
  • 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식
• Client Credentials Grant(클라이언트 자격 승인)
  • Client가 컨텍스트 외부에서 엑세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식
  • OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용 Autorization Code Grant (권한 부여 코드 승인)

Implicit Grant (암묵적 승인)

Resource Owner Password Credentials Grant (리소스 소유자 암호 자격 승인)

Client Credentials Grant Type (클라이언트 자격 승인)

참고 문서

OAuth와 춤을 https://d2.naver.com/helloworld/24942
OAuth2.0란? https://doqtqu.tistory.com/295