OAuth 2.0

Tags:

Oauth 1.0의 개념

주요특징

  1. API를 인증함에 있어 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증 할 수 있다.
  2. 인증(authentication)과 API 권한 부여(authorization)를 동시에 할 수 있다.

실제 활용 구성도

  1. Redirect통한 정보의 요청
  2. 컨슈머에 인증토큰을 전달

개념정리

  1. OAuth1.0 : 인증 + 권한
  2. 토큰의관리는컨슈머가관리
  3. 컨슈머의부하증가
  4. 인증의부담의감소
    • 대형 사이트 및 사용자의 증가에 따른 인증 부담 증가
    • 다수의클라이언트및컨슈머의증가에따른관리비용 감소

OAuth2.0의 개념

주요특징

  1. 추가항목
    • Refresh Toekn: Access Token만료시 사용
    • Exprie:만료시간
    • 다양한모드의제공–Web브라우저외의활용 4. Role의 변화 : 3rd party지원
  2. 인증토큰(1.0과 유사)
    • 컨슈머가 아이디/패스워드를 가지지 않고 API를 사용할 수 있음
    • 필요한 API에만 제한적으로 접근할 수 있도록 권한 제어 가능
    • 사용자가 서비스 프로바이더의 관리 페이지에서 권한 취소 가능
    • 패스워드 변경 시에도 인증 토큰은 계속 유효함.
  3. Role
    • Resource Owner : 사용자
    • Resource Server : API 서버
    • Authorization Server : 인증서버 (API 서버와 같을 수도 있음) Client : 써드파티 어플리케이션

구성도

자원 소유자와, 인증서버, 자원 서버로 분리함

Oauth

구성요소

다양한 토큰 지원(Access token)

  • OAuth 2.0은 기본적으로 Bearer 토큰, 즉 암호화하지 않은 그냥 토큰을 주고받는 것으로 인증을 한다.
  • 기본적으로 HTTPS 를 사용

Authorization: Bearer

또한 OAuth 2.0은 MAC 토큰과 SAML 형식의 토큰을 지원할 수 있지만 현재 MAC 토큰 스펙은 업데이트 되지 않아 기한 만료된 상태이고 SAML 토큰 형식도 아직은 활발하게 수정 중이기 때문에 Bearer 토큰 타입만 지원한다.

Refresh token

클라이언트가 같은 access token을 오래 사용하면 결국은 해킹에 노출될 위험이 높아진다. 그래서 OAuth 2.0에서는 refresh token 이라는 개념을 도입했다.

  • 인증 토큰(access token)의 만료기간을 가능한 짧게
  • 만료가 되면 refresh token으로 access token을 새로 갱신하는 방법이다

API 권한 제어 (scope)

  • OAuth 2.0은 써드파티 어플리케이션의 권한을 설정하기 위한 기능.
  • scope의 이름이 스펙에 정의되어있지는 않으며 여러 개의 권한을 요청할 때에는 콤마등을 사용해서 로그인 시에 scope를 넘겨주게 된다.
  • http://example.com/oauth?....&scope=read_article,update_profile

Authorization code

  • 최초 인증서버를 통해 인증된코드로 AccessToken을 발급받기 위한 코드

Oauth 2.0 grant flow 유형

Authorization code grant flow : 권한 부여 코드 승인

  • 가장 대중적인 방식이다.
  • 주로 웹 어플리케이션에 활용한다.
  • Redirect base / 서버 백엔드가 있는 경우 사용 - 파트너사가 API를 사용하는 시나리오에 유리하다.
  • Service Provider가 제공하는 인증 화면에 로그인하고 클라이언트 앱이 요청하는 리소스 접근 요청을 승인하면, 지정한 redirect_uri로 code를 넘겨주는데. 해당 code로 access_token을 얻는다.

OAuth

Implicit grant flow : 암시적 승인

  • Authorization Code와 flow가 비슷하다.
  • 인증 후 redirect_uri로 직접 access_token을 전달받으므로, 전체 프로세스는 좀 더 간단해지지만 Authorization Code 방식에 비해 보안성은 떨어진다.
  • Rediect base / 특히 Javascript 처럼 서버 백엔드가 없는 경우 유용하다. 스크립트 단에서는 credential 등이 노출 될 수 있으니, 주로 Read only 용도로 많이 사용함. accessToken이 노출될것을 전제로 한다.
  • 모바일 애플리케이션도 많이 사용한다.

OAuth

Resource owner password credential grant flow : 리소스 소유자 암호 자격 증명

  • 직접 ID,PASSWORD를 보내는 방식으로, 1’st level 파트너나 자사 시스템에 많이 사용. 기존의 HTTP BASIC이나 HTTP Digest 인증 방식을 migration하기가 용이하다.
  • Resource Owner가 직접 Client에 아이디와 패스워드를 입력하고 Authorization 서버에 해당 정보로 인증받아 access_token을 직접 얻어오는 방식이다.
  • access token을 얻어올 때 Client에 아이디 패스워드가 노출되어 보안이 떨어지므로 일반적으로 공식 애플리케이션에서만 사용한다.

OAuth

  • Client Id, Secret을 앱에 넣은 후, Client Id/Password로 인증하여, access token을 발급 받는 방식으로, Authorization Server와 Resource Owner가 같은 서비스인 경우 유용함 (자사 API 제공에 유용)

Client credential grant flow : 클라이언트 자격 증명

  • 사용자 없이 client와 직접 통신 구조이다.
  • access_token을 얻는데 정해진 인증 key(secret)로 요청하며, 일반적인 사용보다는 server 간 통신을 할 때 사용한다.

OAuth

유의점

  • TOKEN은 정보 제공 측면에서 활용을 권장
  • 빌링등 Critical한 부분에서는 2중 인증을 필요로 함
  • TOKEN활용은 APP스토어 및 3rd party를 위한 인증서버의 부하 감소 및 ID/PWD의 노출을 방지하기 위한 방안으로 사용됨
  • TOKEN은 비 암호화 되어 있음으로 이를 암호화 처리할수도 있으나 그대로 사용하는 것을 권장
  • TOKEN은 1회성임으로 재인증시 기존 TOKEN은 삭제됨



최종 수정 : 2024-01-18