• OAuth 2.0

    • 인증 절차를 밟을 수 있도록 하는 개방형 표준 프로토콜
    • 리소스 오너가 외부 애플리케이션에게 리소스 접근 권한을 부여하는 권한 부여 프로토콜이다.
  • 주요 개념

    • 리소스 오너
      • 일반 사용자
      • 리소스에 접근할 수 있는 자격을 부여해주는 주체
    • 클라이언트(=애플리케이션)
      • 하나의 서비스를 여러 사용자가 사용하고 있을 경우, 클라이언트 ID로 이들을 식별한다.
    • 리소스 서버
      • 리소스 소유자의 (보호된) 리소스를 호스팅 하는 서버
    • 권한 서버
      • 인증/인가를 수행하는 서버
      • 클라이언트의 접근 자격을 황니한 후, 액세스 토큰 발급하는 역할 수행
  • 프로토콜에 따라 다음 4가지 방식으로 나뉜다. (단, 가장 보편적으로 쓰이는 권한 부여 승인 코드 방식 위주로 기술할 것이다.)

    • 권한 부여 승인 코드 방식(Authorization Code Grant)
    • 암묵적 승인 방식(Implicit Grant)
    • 자원 소유자 자격증명 승인 방식(Resource Owner Password Credentials Grant)
    • 클라이언트 자격증명 승인 방식(Client Credentials Grant)
  • Authorization Code Grant

    • 자체 생성한 Authoriztion Code를 전달하는 방식으로, 간편 로그인 기능 구현 시 주로 사용된다.

      auth-code-flow.png

    • 프로세스
      • 리소스 사용자의 리소스 사용 요청
      • 클라이언트는 권한 서버에게 권한 부여 승인 코드 요청
        • 요청에 포함되는 파라메터: client_id, redirect_url, response_type = code
        • 참고로 redirect_url 은 사용자를 리디렉션 하는데 사용되며 안드로이드의 경우, 해당 url은 activity로 연결된다.
        • client_id 는 앱을 사용하는 사용자들의 클라이언트(엔드포인트)를 구분한다.
      • 권한 서버는 리소스 소유자의 브라우저에 로그인(Consent Grant) 페이지 출력
        • 로그인이 왜 필요한가?
          • 리소스 요청자가 리소스 소유자인지를 확인하기 위해, 본인 인증(로그인)이 필요하다.
        • 어째서 클라이언트서 로그인을 수행하지 않는가?
          • 클라이언트에서 해당 리소스 업체의 로그인 UI를 직접 그릴 수는 없다.
          • 따라서 브라우저로 로그인을 유도한 후, 그 결과를 redirect_url 을 통해 내려주도록 한다.
      • 리소스 소유자는 브라우저를 통해 로그인 시도하고 로그인 성공
      • 권한 서버는 (권한 부여 승인 코드 요청 과정에서 전달받은) redirect_url로 Authorization Code 전달
        • 권한 부여 승인 코드 요청 시, 포함된 파라메터에 redirect_url 인 https://client/callback 이 포함되어 있다고 가정하자
        • https://client/callback 에 인증코드를 붙인 https://client/callback&code=3 를 응답으로 내려준다.
      • 리소스 소유자가 Authorization Code가 포함된 redirect_url 링크 클릭하면 클라이언트 앱으로 리디렉션된다.
      • 이후 리디렉션 된 곳에서 Authorization Code를 가지고 액세스 토큰을 요청한다.
        • 요청 시 포함되는 파라메터: client_id, redirect_url, grant_type = authorization_code, code
      • 권한 서버는 액세스 토큰을 내려준다.
      • 클라이언트는 (올바른 리소스 소유자가 사용 중이므로) 주어진 액세스 토큰으로 리소스 서버에 접근할 권한을 얻고, 자원을 요청할 수 있게 된다.
  • 액세스 토큰과 리프레시 토큰

    • 액세스 토큰
      • 요청 절차를 정상적으로 종료한 클라이언트에게 발급된다.
    • 리프레시 토큰
      • 한번 발급받은 액세스 토큰은 사용할 수 있는 시간이 제한되어 있다.
      • 대게 액세스 토큰과 동시에 발급되나, 만료기한 자체는 액세스 토큰보다 훨씬 길다.
    • 사용 예시
      • 액세스 토큰 만료
      • 토큰이 만료됨을 알아챈 클라이언트는, 리프레시 토큰을 권한 서버에 보내 새로운 액세스 토큰을 요청한다.
      • 서버는 리프레시 토큰의 유효성을 검증한 후, 새로운 액세스 토큰을 발급한다.
      • (이 과정에서 옵션에 따라 리프레시 토큰도 새롭게 발급될 수 있다.)