기타/HTTP & 인증체계

[인증체계] OAuth 2.0 정리 with OAuth

just-e 2020. 10. 12. 06:21

OAuth 2.0 이란?

서비스간 인증 정보를 공유 -> 하나의 인증 서비스로 여러 서비스의 인증을 지원합니다.

  • OAuth 2.0 은 인증 프레임워크로, 업계 표준 프로토콜입니다.
  • 다양한 플랫폼 환경에서 인증 & 권한을 제공합니다.

간단하게 인증(Authentication)과 권한(Authorization)을 획득하는 것입니다.

  • 인증 : 인증은 시스템 접근을 확인하는 것.(로그인)
  • 권한 : 권한은 행위의 권리를 검증하는 것.
ex) 별도의 회원가입 없이 로그인을 제공하는 것으로,
     플랫폼의 아이디만 있으면 서비스 이용 가능합니다.

[그림 2], 인증(Authorization) 부분 참고 그림.

 

OAuth & OAuth 2.0 등장배경

  • OAuth가 사용되기 전, 인증 방식의 표준 없습니다..  ==> 기본 인증인 ID/PW 사용은 보안상 취약한 구조가 문제입니다.
  • OAuth는 제 각각인 인증방식을 표준화한 인증 방식입니다.  ==> 인증 공유 -> 애플리케이션 통합 가능합니다.
ex) 구굴의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있습니다.

역사

  • 2006년 11월 브레인 쿡, 크리스 메시나, 래리 하프(Ma.gnolia)는 데이비드 리코던과 만나 OpenID를 활용해 트위터나 Ma.gnolia의 API로 인증을 위임하는 방법을 논의했습니다..
  • 그 결과, API 접근 위임에 대한 공개 표준이 없음을 알게 됩니다.
  • OAuth의 인터넷 커뮤니티는 2007년 4월에 탄생하여, 소수 인원으로 새로운 공개 프로토콜의 초안을 작성.
      -> 2007년 7월 사양 초안 완성. -> 2007년 10월 3일, OAuth 코어 1.0 초안 발표.
  • 2008년 11월 IETF에서 정식으로 OAuth 작업모임을 발족시키는 일에 폭넓은 지지를 얻습니다.
  •  

OAuth & Oauth 2.0 개요

  • 3rd party(Third party Application)를 위한 범용적인 인증 표준입니다.
  • ID/PW를 신뢰못하는 곳에 저장하지 않아도 됩니다.
  • 원하는 권한 줄 수 있으며, 원할 때 권한 회수가 가능합니다.
  • 다른 서비스를 통해 로그인을 할 수 있다.
  • OAuth 1.0에 불편한 점을 개선하고자 나온 것이 OAuth 2.0이며, 목적은 같습니다.

 

OAuth 1.0 vs OAuth 2.0

OAuth 2.0은 OAuth 1.0의 보안 문제 등을 개선한 버전으로 OAuth 1.0을 대체합니다.

특징 OAuth 1.0 OAuth 2.0 예시
역할 이용자(User) - 자원 소유자(Resource Owner) 홍길동
소비자(Consumer) - 클라이언트(Client) 쇼핑몰
서비스 제공자
(Service Provider)
- 자원 서버(Resource Server)
- 권한 서버(Authorization Server)
페이스북
API 호출 인증 및 보안 서명 - HTTPS(SSL/TLS) 기본 지원.
- 여러 인증 방식을 통해 다양한 시나리오에 대응 가능.
- Access Token의 Life Time을 지원하여 만료일 설정 가능.
 
클라이언트 지원 유형 웹 애플리케이션 - 다양한 플랫폼 지원  
Access Token Access Token 발급시
계속 사용 가능.
- 보안 강화를 위해 Access Token의 Life-time을 지정 가능.  

< OAuth 1.0과 OAuth 2.0의 주요 차이점 비교 >

 

OAuth 2.0의 4가지 인증방식

권한 코드 인증 - 권장
(Authorization Code Grant)
암묵적 인증 - 권장
(Implicit Grant)
클라이언트 유형
  • 서버 웹 애플리케이션.
  • 네이티브 애플리케이션(백엔드 서버 사용).
장기적 접근
  • 재발급 토큰을 통해 지원.
보안성
  • 이용자 웹 브라우저를 통해 접근 토큰이 노출되지 않도록 권한 코드 사용.
  • 클라이언트는 권한 코드를 사용하여 권한 서버에게 직접 적근 토큰을 요청.
  • 중요 자격증명 정보가 서버에 저장되기 때문에 다른 권한 승인 방법에 비해 안전함.
클라이언트 유형
  • 이용자 에이전트 애플리케이션.
장기적 접근
  • 재발급 토큰 미지원으로 인해 접근 토큰의 유효기간이 짧으면 장기적 접근 불가..
보안성
  • 접근 토큰이 웹 브라우저에 전달 및 저장되기 때문에 웹 브라우저, 클라이언트, 이용자에 대한 신회가 높은 경우에 적합.
  • 접근 토큰 유출을 고혀라여, 접근 토큰의 유효 기간에 대한 적절한 조절이 필요함.

자원 소유자 비밀번호 자격증명 인증 - 비권장
(Resource Owner Password Credentials Grant)
클라이언트 자격증명 인증 - 비권장
(Client Credentials Grant)
클라이언트 유형
  • 모든 클라이언트 유형 가능.
  • 일반적으로 API 제공 업체가 배포한 애플리케이션.
장기적 접근
  • 재발급 토큰을 통해 지원.
보안성
  • 자원 소유자의 비밀번호가 애플리케이션에 노출되고, 피싱 위험이 존재.
  • 접근 토큰 발급 요청시에만 비밀번호가 사용되기 때문에 클라이언트에 인증정보를 지정할 필요 없음.
클라이언트 유형
  • 클라이언트가 데이터를 소유하고 있거나, 접근 위임이 이미 허용된 경우.
장기적 접근
  • 재발급 토큰을 통해 지원.
  • 클라이언트 인증만으로 즉시 접근 토큰 재발급 가능.
보안성
  • 클라이언트 인증만으로 접근 토큰을 발급하기 떄문에 안전한 인증 방식 사용 및 인증 정보의 규칙적인 변경이 필요함.

 

4가지 인증방식 선택

[그림 3], 4가지 인증방식 선택

 

OAuth 2.0의 SSO Flow

[그림 4], OAuth SSO 인증 Flowchart

 

SSO with Spring Security OAuth 2.0

[그림 5], OAuth 2.0 인증을 통한 SSO Flowchart

 

참고 자료

IETF REC6749 - The OAuth 2.0 Authorization Framework

OAuth 공식사이트

PAYCO

nexttree - OAuth 2를 이용한 SSO

Simple Single Sign-On with Spring Security OAuth2

[문서] OAuth2.0 개요 및 보안 고려사항. - 금융보안원