OAuth2

◎ OAuth 2.0 (OAuth2)

• OAuth 2.0

  • 보안된 리소스를 액세스 하기 위해 클라이언트에게 권한을 제공(Authorization)하는 프로세스를 단순화하는 프로토콜(통신 규약) 중 한 방법이다.
  • 인증을 중개해 주는 메커니즘
  • 이미 사용자 정보를 가지고 있는 웹 서비스에서 사용자의 인증을 대신해 주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용해 내 서버에서 인증이 가능

• OAuth 사용 이점

  • 자주 사용하고 중요한 서비스들의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 소셜 로그인을 할 수 있다.
  • 직접 유저의 민감한 정보가 App에 노출될 일이 없고 인증 권한에 대한 허가를 미리 유저에게 구해야 하기 때문에 더 안전하게 사용 가능

◎ OAuth에서 사용하는 용어

• Resource Owner : 액세스 중인 리소스의 유저
• Client : 보호된 리소스에 액세스하는 어플리케이션 (Resource Server, Authorization Server에 요청을 보내는 App)
• Resource Server : 클라이언트의 요청을 수락하고 응답할 수 있는 서버 (해당 자료가 있는 서버, 인증 역할)
• Authorization Server : 리소스 오너를 성공적으로 인증한 후 클라이언트에게 액세스 토큰을 발급하는 서버 (인가 역할)
• Authorization Grant : 클라이언트가 액세스 토큰을 얻는 방법
  • 여러 종류가 있음, 아래에 자세히 설명
• Authorization Code
  • Authorization Grant의 한 타입으로 액세스 토큰을 발급받기 위한 Code
  • Client ID로 이 Code를 받아온 후, Client Secret과 Code를 이용해 액세스 토큰을 받아올 수 있다.
• Access Token
  • 보호된 리소스에 액세스하는 데 사용되는 인증 토큰
  • Authorization Code와 Client Secret을 이용해 받아온 이 Access Token으로 이제 리소스 서버에 접근 가능
• Scope
  • 토큰의 권한을 정의 (액세스할 수 있는 리소스의 범위 정의)
  • 특정 접근 권한을 지정 가능

◎ Authorization Grant Type (OAuth2 동작 방식)

• 기본 용어

  • Client : 권한 부여를 요청하는 App
    • 현 상황에서는 내가 만들려는 App에 해당
  • Server : 요청 응답 및 리소스를 가지고 있는 App
    • 현 상황에서는 Kakao, facebook 등이 해당
  • Client와 Server의 개념은 상황에 따라 상대적이므로 상황에 맞추어 파악해야 함

• Grant type 종류

  • Authorization Code Grant Type
  • Refresh Token Grant Type
  • Implicit Grant Type
  • Client Credentials Grant Type
  • Resource Owner Credentials Grant Type

• Authorization Server의 종류에 따라 사용하는 방식이 다르므로 각 사이트(Kakao, facebook ...)마다 공식 문서를 확인하여 작업할 것

◎ Authorization Code Grant

• 권한 부여 승인 코드 방식

  • 가장 많이 쓰이고 기본이 되는 방식

• 과정

  • 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달
    • 권한 부여 승인 요청시, 응답 타입(response_type)을 code로 지정하여 요청
  • Authorization code를 받아 액세스 토큰과 교환

• 목적

  • Authorization Code 절차를 거치는 이유 : 보안성 강화
    • Client에서 client-secret을 공유하고 엑세스 토큰을 가지고 오는 것은 탈취의 위험이 있기 때문에 Client 에서는 authorization code만 받아오고 Access token 요청을 진행

  

◎ Refresh Token Grant Type

• 일정 시간 유효 기간이 지나서 만료된 액세스 토큰을 편리하게 다시 받아오기 위해 사용하는 방법
• 특징
  - Access token보다 Refresh token의 유효 기간이 대체로 조금 더 길게 설정함
  - Refresh token 을 사용하기 위해서는 사용하고자 하는 server의 정책을 봐야함 (server 마다 Refresh token의 정책이 다름)
  

◎ Client Credentials Grant

• 클라이언트 자격 증명 방식

• 사용 가능 조건

  • 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용 가능
  • 자격 증명을 안전하게 보관할 수 있는 클라이언트에서만 사용, 리프레시 토큰의 사용은 불가

◎ Implicit Grant

• 암묵적 승인 방식

  • 별도의 권한 부여 승인 코드 없이 바로 액세스 토큰을 발급하는 방식
    • 권한 부여 승인 요청시 응답 타입(response_type)을 token으로 지정하여 요청
  • 자격증명을 안전하게 저장하기 힘든 클라이언트에게 최적화된 방식
  • Authorization Server는 client secret을 통해 클라이언트 인증과정을 생략
    (Authorization Code Grant보다 보안에 취약)

• 리프레시 토큰 사용이 불가

◎ Resource Owner Password Credential Grant

• 자원 소유자 자격 증명 승인 방식

  • 간단하게 로그인시 필요한 정보(username, password)로 액세스 토큰을 발급받는 방식
  • 리프레시 토큰의 사용 가능

• 사용 가능 조건

  • 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때만 사용이 가능
    • ex) 네이버 계정으로 네이버 웹툰 애플리케이션에 로그인
    • ex) 카카오 계정으로 카카오 지도 애플리케이션에 로그인

  

◎ OAuth2 구현 예시

• Github OAuth2 예시 (내 블로그)