OAuth이란 무엇인가?

OAuth는 인증을 위한 업계 표준 프로토콜로써 클라이언트 개발자 단순성에 중점을 두면서 웹 애플리케이션, 데스크톱 애플리케이션, 휴대폰 및 거실 장치에 대한 특정 권한 부여 흐름을 제공합니다.

최근 서비스에서 별도의 회원가입없이 로그인을 제공해주는 플랫폼의 아이디가 있다면 해당 서비스를 이용할수 있는데요.

OAuth는 이러한 외부 타사의 정보를 접근, 사용할수 있는 권한을 인가(Authorization)받을수 있게 합니다.

이러한 OAuth를 사용하는 이유는 일반적인 애플리케이션서비스에 권한 획득을 위한 개인정보를 사용하여 회원가입하는것이 사용자 입장에서도 부담이 될수 있기 때문에 타사의 정보(Kakao, Naver, Google, Github)를 사용하여 로그인을 진행하는것이 사용자 입장에서 좋습니다.

OAuth 동작에 참여하는 참여자

• Resource Server : Client가 제어하고자 하는 자원(타사의 정보)을 보유하고 있는 서버, 즉 타사(Google, Github, Kakao, Naver)등이 해당됩니다.

• Resource Owner : 자원의 소유자, 즉 Client가 제공하는 서비스를 통해 로그인하는 실제 유저가 이에 속합니다.

• Client : Resource Server에 접속하여 정보를 가져오고자 하는 클라이언트입니다.

• Authorization Server : 권한서버 인증/인가를 수행하는 서버로써 클라이언트의 접근 자격을 확인하고 Access Token을 발급받아 권한을 부여하는 역활을 수행합니다.

동작 과정

Client가 Resource Server의 API를 사용하기위하여 Resource 서버에 등록을 해야합니다. 등록을 하게되면 Client를 식별할수 있는 Client ID와 Client Secret을 발급 받습니다.

주요 API Parameter

• client_id, client_secret : 클라이언트 자격증명. 클라이언트가 권한 서버에 등록하면 발급받을 수 있으며 권한 서버 연동 시 클라이언트의 검증에 사용됩니다.
• redirect_url : 권한 서버가 요청에 대한 응답을 보낼 url을 설정합니다.
• response_type : 권한 부여 동의 요청 시 포함되는 값으로 권한 부여 방식에 대한 설정입니다. 아래 값 중 한 개를 사용합니다.
  • code: Authorization Code Grant
  • token: Implicit Grant
• state : CSRF 공격에 대비하기 위해 클라이언트가 권한서버에 요청 시 포함하는 임의의 문자열. 필수 사항은 아니지만 클라이언트가 요청 시 state를 포함 시켰다면 권한 서버는 동일한 값을 클라이언트에게 보내야 합니다.
• grant_type : Access Token 획득 요청 시 포함되는 값으로 권한 부여 방식에 대한 설정입니다. 아래 값 중 한 개를 사용합니다.
  • authorization_code: Authorization Code Grant
  • password: Resource Owner Password Credentials Grant
  • client_credentials: Client Credentials Grant
• code : Authorization Code 방식에서 Access Token요청 시 사용됩니다. 권한 서버에서 획득한 Authorization Code를 입력합니다.
• token_type : 발행된 Token의 타입. 대표적으로 Bearer, MAC(Message Authentication Code)가 있습니다.
• expires_in : 토큰 만료 시간(단위: 초)
• example_parameter : Token 타입에 따른 추가 파라미터

OAuth Access Token

• OAuth 엑세스 토큰은 OAuth 클라이언트가 리소스 서버에 요청하는데 사용하는 문자열입니다.
• 엑세스 토큰은 특정 형식일 필요가 없으며 실제로 다양한 OAuth서버에서 엑세스 토큰에 대해 다양한 형식을 선택했습니다.

OAuth Refresh Token

• Access Token 만료시 이를 갱신하기 위한 용도로 사용되는 Token으로써 일반적으로 Access Token보다 만료기간이 길다.

OAuth Access Token을 얻는 방식(**OAuth Grant Types)**

• Authorization Code 방식

  

  • 권한 부여 승인 코드 부여 유형은 기밀 및 공개 클라이언트가 액세스 토큰에 대한 인증 코드를 교환하는데 사용됩니다. 권한 서버는 사용자가 로그인시 클라이언트가 전에 권한 부여 승인 요청시 전달한 Redirect URL을 통해 권한 부여 코드를 전달합니다. 그후 클라이언트는 권한 부여 승인 코드를 가지고 Access Token을 요청합니다.

• PKCE(Proof Key for Code Exchange)

  • PKCE는 CSRF 및 인증 코드 삽입 공격을 방지하기 위한 Authorization Code 방식의 확장입니다.

  • PKCE는 위에서 정리한 방식에 Code Verifier와 Code Challenge를 추가하여 Authorization code가 탈취 당했을떄 Access Token을 발급하지 못하게 막을수 있습니다.

    Code Verifier 생성 규칙

    48 ~ 128 글자수를 가진 Random String

    A - Z, a - z, 0 - 9, - _ ~ 문자들로만 구성됩니다.

    Code Challenge 생성 규칙

    선택한 Hash 알고리즘(SHA256 등)으로 Code Verifier를 해싱한후 Base64 인코딩한 값입니다.

  • 권한 부여 승인 코드 요청시 Code Challenge와 Code Challenge를 Hashing한 hash함수 종류를 쿼리 파라미터에 추가합니다.
  • Access Token을 요청시에는 Code Verifier를 전달합니다.
  • 권한 부여 승인코드 요청시 전달한 Code Challenge와 Access Token 요청시 전달한 Code Verifier를 해싱하고 base64 인코딩하여 비교합니다.

• Implict 방식

  

  • 암묵적 승인 방식이라고도 불리는 Implict 방식은 자격증명을 안전하게 저장하기 힘든 클라이언트 에게 최적화된 방식으로써 권한 부여 승인 코드 없이 바로 Access Token이 발급되는 방식입니다.
  • Refresh Token 사용이 불가능하며 Access Token이 바로 전달되므로 만료 기간을 짧게 설정하여 누출의 위험을 줄이는것이 좋습니다.
  • 이 방식에서 권한 서버는 Client Secret으로 클라이언트를 인증하지 않습니다. Access Token을 획득하기 위한 절차가 간소화되어 응답성과 효율성은 높아지지만, Access Token이 Redirect URL로 전달된다는 단점이 있습니다.

• Resouce Owner Password Credentials 방식

  

  • API를 통해 username,password을 전달하여 Access Token을 전달 받는 방식
  • 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식으로써 Refresh Token의 사용도 가능합니다.

• Client Credentials 방식

  

  • 클라이언트의 자격 증명만으로 Access Token을 획득하는 방식으로써 간단한 방식입니다.
  • 클라이언트가 관리하는 리소스 혹은 권한서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다.
  • 보안적으로 취약할수 있으며 ClientSecret이 유출되지 않도록 주의 해야합니다.

• Refresh Token 방식

  • Refresh Token 방식은 Access Token이 만료된 경우 클라이언트가 Refresh Token을 Access Token으로 교환하는데 사용됩니다. Refresh Token이 Access Token보다 만료시간이 길기 때문에 가능합니다.
  • 이를 통해 클라이언트는 사용자와의 추가 상호 작용 없이 계속 유용한 Access Token을 가질수 있습니다.

OAuth Version

• OAuth 1.0
  • RFC 5849 : The OAuth 1.0 Protocol
  • Session fixation Attack 취약점이 발견되어 1.0 A 버전이 나오게 됨
• OAuth 1.0 개정 A
  • Session fixation Attack 취약점이 발견되어 1.0 A 버전이 나오게 되었지만 2.0 Authorization Framework가 나와서 사용하지 않습니다.
• OAuth 2.0
  • RFC 6749 : The OAuth 2.0 Authorization Framework
  • 많은 패치와 확장이 있었습니다.
• OAuth 2.1 ( Progress)
  • OAuth 2.1은 OAuth 2.0에서 가장 일반적으로 사용되는 기능을 통합하고 단순화하기 위해 진행 중인 노력입니다
  • 2.0과 중요 차이점은 PKCE는 인증 코드 흐름을 사용하는 모든 OAuth 클라이언트에 필요합니다.
  • Redirect URL는 정확한 문자열 일치를 사용하여 비교해야합니다.
  • Implict 방식등 Legacy 방식은 이 버전 에서는 생략되었습니다.
  • 참조
    • https://oauth.net/2.1/

Reference

• https://blog.naver.com/mds_datasecurity/222182943542