Oauth 2.0 & OpenID Connect

Oauth 2.0과 OpenID Connect 프로토콜 정리

• 요즘 웹 사이트나 모바일 앱에서는 구글로 로그인하기, 페이스북으로 로그인하기 등의 버튼을 쉽게 볼 수 있음
  • 해당 버튼을 누르게 되면 창이 하나 뜨면서 이 앱은 당신의 프로필에 접근하려 합니다. 등의 메세지를 띄움
  • 이러한 기능들을 적용하는데 일반적으로 OAuth를 이용
  • 이러한 프로토콜은 소프트웨어 엔지니어, 보안 전문가, 해커도 충분히 알 필요성이 있는 중요한 내용

• 짧게 요약하자면, OAuth 2.0과 OpenID Connect는 인증과 권한 관리를 위해 요즘 인터넷에서 가장 널리 쓰이고 있는 프로토콜들
  • OAuth 2.0은 권한 관리를 위해 사용
  • 그리고 OpenID Connect는 인증을 위해 사용
  • 가장 널리 쓰이는 OAuth 2.0 인증은 두 가지 플로우가 있는데, 서버사이드 어플리케이션을 위한 플로우와 브라우저를 베이스로한 앱을 위한 묵시적 플로우가 있음
  • OpenID Connect는 OAuth를 권한에 대한 유즈 케이스들에 적합하게 만들기 위해 OAuth 2.0 프로토콜의 가장 상위 레이어에 있음

OAuth를 사용하는 이유

• OAuth의 탄생을 이해하기 위해서는 위임 권한 부여(Delegated Authorization)라 불리는 용어를 알아야 함

위임 권한 부여 (Delegated Authorization)

• 위임 권한 부여(Delegated Authorization)는 서드파티 어플리케이션이 사용자의 데이터에 접근하도록 허락해주는 것

Tip! 서드파티란?

• 하드웨어 생산자와 소프트웨어 개발자의 관계를 나타낼 때 사용
  • 그 중에서 서드파티(3rd Party)는 프로그래밍을 도와주는 라이브러리를 만드는 외부 생산자를 뜻함
  • 편한 개발을 위해 플러그인이나 라이브러리 혹은 프레임워크를 사용하는데, 이처럼 제 3자로 중간다리 역할로 도움을 주는 것이 서드파티로 볼 수 있음

위임 권한 부여 두 가지 접근법

• 위임 권한 부여에는 두 가지 접근법이 존재
  • 서드파티 어플리케이션에 아이디와 비밀번호를 줘서 사용자 대신에 사용자의 계정에 로그인을 하거나 사용자의 데이터에 접근하게 할 수 있음
    • 사실 패스워드를 주는 방법은 어디에서도 쓰이지 않을 것
  • 또는 OAuth를 이용해 서드파티 어플리케이션에게 사용자 데이터에 대한 접근 권한을 줄 수도 있음

OAuth란?

• OAuth(Open Authorization)은 위임 권한 부여를 위한 표준 프로토콜
  • OAuth는 어플리케이션이 사용자의 패스워드 없이 사용자의 데이터에 접근 가능하도록 허가

OAuth 2.0 용어 정리

• 리소스 소유자 (Resource Owner)
  • 클라이언트 어플리케이션이 접근하길 원하는 데이터를 가지고 있는 사용자

• 클라이언트 (Client)
  • 사용자의 데이터에 접근하고 싶어하는 어플리케이션

• 권한부여 서버 (Authorization Server)
  • 사용자로부터 권한을 부여받음으로써 클라이언트가 사용자의 데이터에 접근할 권한을 부여해주는 권한부여 서버

• 리소스 서버 (Resource Server)
  • 클라이언트가 접근하길 원하는 데이터를 갖고 있는 시스템
  • 때때로 권한부여 서버와 리소스 서버가 같은 경우가 있음

• 액세스 토큰 (Access Token)
  • 리소스 서버에서 사용자에 의해 부여된 데이터에 접근하기 위해서 클라이언트가 사용할 수 있는 유일한 키가 바로 이 엑세스 토큰

권한 부여 플로우

• 권한 키•인가는 타입 코드 또는 토큰이 될 수 있음
• 먼저 권한 부여 플로우를 자세히 다룰 예정

• ① 사용자가 권한 부여 플로우를 시작
  • 주로 구글로 로그인하기, 페이스북으로 로그인하기와 같은 버튼을 눌러서 시작
• ② 클라이언트는 사용자를 권한 부여 서버로 리다이렉트 시킴
  • 리다이렉트를 시킬 때 클라이언트는 권한 부여 서버에게 클라이언트 ID 그리고 리다이렉트 URI와 같은 정보를 전달
• ③ 권한 부여 서버는 인증을 처리하기 위해 사용자의 동의를 구하는 화면을 표출한 뒤 클라이언트에게 허가를 내줌
  • 만일 사용자가 구글로 로그인하기 버튼을 눌렀다면 사용자는 반드시 구글에게 로그인 자격을 제공해야 함
  • 이를테면 account.google.com과 같은 사이트에서 로그인하는 것을 말하며 클라이언트는 제공하지 않아도 됨
• ④ 사용자가 허가를 내줬다면 권한 부여 서버는 권한 부여 키(코드 혹은 토큰)와 함께 사용자를 클라이언트로 돌려보냄
• ⑤ 클라이언트는 리소스 서버에게 권한 부여 키를 이용하여 사용자의 데이터에 대한 응답을 요청
• ⑥ 리소스 서버는 권한 부여 키의 유효성 검사를 한 뒤에 요청된 데이터를 클라이언트에게 보내줌

• 위의 내용은 사용자가 서드파티 어플리케이션에게 직접 패스워드를 주지 않으면서 어떻게 데이터에 접근할 수 있게 하는지에 대한 방법
  • 해당 방법에 대한 의문점
    • 어떻게 리소스 서버에서 특정한 데이터에만 접근이 가능하도록 제한할까?
    • 만일 클라이언트가 데이터를 읽기만 바라고 수정하지는 않길 바란다면?
  • 이러한 의문들은 OAuth 용어에서 스코프(scope)라는 개념을 알면 이해 가능

OAuth의 스코프

• OAuth 2.0에서 스코프(scope)는 어플리케이션이 사용자 데이터에 접근하는 것을 제한하기 위해 사용
  • 사용자에 의해 특정 scope로 제한된 권한 인가권을 발행함으로써 데이터 접근을 제한

• 클라이언트가 권한 인가를 위해 권한 부여 서버로 요청을 보낼 때, 클라이언트는 scope도 함께 보냄
  • 권한 부여 서버는 동의를 구하는 화면을 만들고 사용자로부터 허가를 받기 위해 scope의 리스트를 사용
  • 만일 사용자가 동의 화면에서 동의했다면 그 권한 부여 서버는 유저에 의해 부여된 scope에 제한된 토큰 또는 권한 부여 코드를 발행

• 예를 들어, 만일 클라이언트에게 나의 구글 연락처의 리스트를 볼 수 있게 하기 위해 권한을 부여했을 경우
  • 권한 부여 서버로부터 발행되어 클라이언트로 전해진 토큰은 나의 연락처를 삭제하거나 나의 캘린더 이벤트를 볼 수는 없음
  • 왜냐하면 오직 구글 연락처를 읽도록 scope가 설정되어 있기 때문

OAuth 2.0을 위한 설정

• OAuth 플로우에 대해 배워보기 전에 몇 가지 OAuth 설정에 대해 미리 알아두면 좋음
• 권한 부여를 위한 요청이 초기화되었을 때, 클라이언트가 몇가지 설정 데이터를 권한 부여 서버에게 쿼리 파라미터로 보냄

기본적인 쿼리 파라미터

• response_type
  • 클라이언트가 권한 부여 서버로부터 받길 원하는 응답의 타입
• scope
  • 클라이언트가 접근하길 원하는 리스트의 스코프
  • 이 리스트는 동의를 구하는 화면을 만들 때 권한 부여 서버에 의해 사용
• client_id
  • 클라이언트에 OAuth 세팅을 할 때 권한 부여 서버에 의해 제공됨
  • 이 ID는 권한 부여 서버가 OAuth 플로우를 시행하려는 클라이언트가 누구인지 알아내기 위해 사용
• redirect_url
  • 권한 부여 서버에게 OAuth 플로우가 끝나면 어디로 보내줄지에 대해 알려주는 역할
• client_secret
  • 권한부여 서버에 의해 제공
  • OAuth 플로우에서 이 파라미터는 필수 옵션은 아니지만 권한부여 코드 플로우에서 이 client_secret의 중요성에 대해 알아볼 예정

다른 OAuth 플로우들

• 가장 흔하게 쓰이는 두 가지 OAuth 2.0 플로우는 서버를 베이스로한 어플리케이션을 위한 권한 부여 코드 플로우와 순수한 자바스크립트 Single Page Application(SPA)을 위한 암묵적인 플로우가 있음

권한 부여 코드 플로우

• 권한 부여 코드 플로우는 보안성을 높이기 위해서 이상적인 OAuth 플로우로 여겨짐
  • 왜냐하면 OAuth 2.0 매커니즘을 구현하기 위해서 프론트엔드 채널도 이용하고 백엔드 채널도 이용하기 때문

• 권한 코드를 부여하고 그 권한 코드를 엑세스 토큰으로 변경하는 부분이 추가되었음

• 클라이언트는 code라고 세팅된 response_type과 함께 사용자를 권한 부여 서버로 리다이렉팅함으로써 권한 부여 시퀀스를 시작
  • 이게 의미하는 바는 권한 부여 서버에게 권한 부여 코드로 응답하라는 것을 말함

# google 예시: URI

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=your_client_id&
scope=profile%20contacts&
redirect_uri=https%3A//oauth2.example.com/code

• 위 요청에서 클라이언트는 요청의 scope 파라미터에 인자를 보냄으로써 사용자의 공개 프로필과 연락처에 접근할 수 있는 사용자의 권한을 요구
  • 이 요청의 결과는 액세스 토큰으로 변환 가능한 권한 부여 코드

# google 예시: 권한 부여 코드

4/W7q7P51a-iMsCeLvIaQc6bYrgtp9

코드를 토큰으로 바꾸는 이유

• 액세스 토큰은 리소스 서버에 존재하는 데이터에 접근하기 위한 유일한 것
  • 하지만 어플리케이션 코드는 아님
• 그런데 왜 액세스 토큰이 필요할 때 클라이언트가 response_type을 code로 세팅하는 것일까?
  • OAuth 플로우의 보안성을 높게 만들기 위함

문제점

• 액세스 토큰은 다른 사람이 접근하면 안되는 정보의 비밀스러운 부분
  • 만일 클라이언트가 액세스 토큰을 직접적으로 요청하고 브라우저에 갖고 있게 되면 탈취당할 수 있음
    • 브라우저는 완전히 보안이 되어있진 않기 때문
  • 다른 사람이 페이지 소스 또는 잠재적으로 개발자 도구로 액세스 토큰을 얻어갈 수 있음

해결 방법

• 브라우저에서 액세스 토큰 노출을 방지하기 위해서, 클라이언트의 프론트엔드 채널은 권한 부여 서버로부터 어플리케이션 코드를 얻음
  • 그리고 어플리케이션 코드를 백엔드 채널로 보냄
  • 어플리케이션 코드를 액세스 토큰으로 바꾸기 위해서 client_secret이 필요
    • client_secret은 클라이언트의 백엔드 채널에 의해서만 알려지게 되며 프론트엔드 채널은 client_secret에 관여하지 않음
  • 백엔드 채널은 POST 요청을 권한 부여 서버에 client_secret와 어플리케이션 코드를 동봉해서 보냄

# google 예시: 요청

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/W7q7P51a-iMsCeLvIaQc6bYrgtp9&
client_id=your_client_id&
client_secret==your_client_secret_only_known_by_server&
redirect_url=https%3A//oauth2.example.com/code

• 권한 부여 서버는 client_secret과 어플리케이션 코드의 유효성을 검사하고 액세스 토큰을 전송
  • 백엔드 채널은 액세스 토큰을 리소스 서버에서 정보를 갖고올 때 사용
  • 이러한 방법으로 브라우저는 액세스 토큰에 접근하지 않는 방식으로 구현할 수 있음

묵시적 플로우

• OAuth 2.0 묵시적 플로우는 백엔드 채널이 존재하지 않으며 웹사이트가 브라우저만 사용하는 정적인 사이트일 때 사용
  • 이 경우에는 어플리케이션 코드를 액세스 토큰으로 변경할 때 백엔드 채널에서 일어나는 마지막 단계를 생략
  • 묵시적 플로우에서는 권한 부여 서버가 액세스 토큰을 바로 전송

• 클라이언트는 response_type이 token으로 설정된 권한 부여 플로우를 시작하기 위해서 브라우저를 권한 부여 서버 URI로 리다이렉트
  • 권한 부여 서버는 사용자의 로그인과 동의를 받음
  • 요청의 결과로 클라이언트가 리소스 서버에 접근할 때 사용할 수 있는 액세스 토큰이 나옴

• 암묵적 플로우는 보안이 조금 더 취약하다고 여겨짐
  • 왜냐하면 브라우저가 액세스 토큰을 들고있기 때문
  • 그래서 잠재적으로 누군가에 탈취당할 수도 있지만 여전히 SPA에서는 이 방법이 많이 쓰임

권한 부여(Authorization)와 인증(Authentication)

• OAuth는 위임된 권한 부여 문제를 해결
  • 하지만 이 방법은 사용자 인증을 위한 표준 방법을 제공해주진 않음

• OAuth 2.0은 권한 부여를 위한 것
• OpenID Connect는 인증을 위한 것

• 권한 부여와 인증의 차이점
  • 권한 부여(Authorization)는 소통하는 주체가 리소스에 접근할 수 있는지 아닌지에 대해 확인하는 프로세스
    • 당신이 어떤 권한을 가졌는지에 대한 것
  • 인증(Authentication)은 소통하는 주체가 어떤 것인지 확신하는 프로세스
    • 당신이 누구인지에 대한 것

OpenID Connect란?

• OpenID Connect는 OAuth 2.0 프로토콜의 최상위 레이어와 동일한 레이어
  • OpenID Connect는 OAuth 2.0을 확장하여 인증 방식을 표준화

• OAuth는 유저 인증을 곧바로 제공하지 않지만 권한 부여를 위한 엑세스 토큰을 제공
• OpenID Connect는 권한 부여 서버에 의해 작동하는 인증 시스템을 기반으로 클라이언트가 사용자를 판단할 수 있게 해줌
  • 권한 부여 서버에 유저 로그인과 동의를 요청할 때 openid라는 scope를 정의하면 OpenID Connect 사용이 가능
    • openid는 OpenID가 필요되는 권한 부여 서버에 필수적인 scope

# google 예시: 요청

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=your_client_id&
scope=openid%20contacts&
redirect_uri=https%3A//oauth2.example.com/code

• 이 요청의 결과는 액세스 토큰과 ID 토큰으로 바꿀 수 있는 어플리케이션 코드
  • OAuth 플로우가 암묵적 플로우면 서버는 액세스 토큰과 ID 토큰을 바로 줄 것

Tip! 추가 내용

• Access Token
  • HTTP Request의 authorization 헤더에 넣은 토큰
  • 일반적으로 JWT 형식을 많이 씀
  • 토큰은 분실의 위험이 있기때문에 보통 30분-1시간의 유효기간을 가짐
  • 어렵긴 하지만 서버에서 토큰을 취소하는 것이 불가능하진 않음
• Refresh Token
  • 새로운 엑세스 토큰을 얻을 수 있는 장기 토큰
  • 보통은 특정 리소스를 위한 엑세스 토큰을 얻음
  • 리프레시 토큰을 안전하게 사용할 수 있는 클라이언트만이 리프레시 토큰을 사용해야 함
• ID Token
  • 유저의 ID
  • 일반적으로 JWT 형식
  • ID 토큰은 절대 인증정보나 어떠한 리프레시 토큰 정보를 가지고 있으면 안됨
  • 유저 ID는 단순하게 사용자를 구분하기 위해 사용함

• ID 토큰은 JWT(JSON Web Token)
  • JWT는 header, payload, signature 3가지 부분이 담겨있는 인코드된 토큰
  • ID 토큰을 얻은 이후에 클라이언트는 payload 부분에 인코드된 사용자 정보를 얻을지 결정할 수 있음

# google 예시: 사용자 정보

{
  "iss": "https://accounts.google.com",
  "sub": "10965150351106250715113082368",
  "email": "[email protected]",
  "iat": 1516239022,
  "exp": 1516242922
}

Claims

• ID 토큰이 갖고 있는 payload는 claims라 알려진 어떤 필드들을 포함

• 기본적인 claims
  • iss : 토큰 발행자
  • sub : 사용자를 구분하기 위한 유니크한 구분자
  • email : 사용자의 이메일
  • iat : 토큰이 발행되는 시간을 Unix time으로 표기한 것
  • exp : 토큰이 만료되는 시간을 Unix time으로 표기한 것

• 하지만 claims는 이러한 영역에 제한된 것이 아님
  • 권한 부여 서버에서 어떻게 claims를 인코드할 것인지에 달린 것
  • 클라이언트는 이러한 정보를 이용하여 사용자를 인증할 수 있음

• 만일 클라이언트가 더 많은 사용자 정보를 원한다면 클라이언트는 표준 OpenID Connect scope에 더 많은 것들을 기재하여 권한 부여 서버에게 ID 토큰의 payload에 필요한 것들을 더 추가하라고 할 수 있음
  • 이러한 scope는 email, address, phone, profile 등이 있음

Tip! 추가 내용

OpenID와 OAuth

• OpenID도 인증을 위한 표준 프로토콜이고 HTTP를 사용한다는 점에서는 OAuth와 같음
  • 그러나 OpenID와 OAuth의 목적은 다름

• OpenID의 주요 목적은 인증(Authentication)이지만, OAuth의 주요 목적은 허가(Authorization)
  • 다시 말해 OpenID를 사용한다는 것은 본질적으로 로그인하는 행동과 같음
    • OpenID는 OpenID Provider에서 사용자의 인증 과정을 처리하는데 Open ID를 사용하는 여러 서비스(Relying Party)는 OpenID Provider에게 인증을 위임하는 것
  • 물론 OAuth에서도 인증 과정이 있음
    • 가령 Facebook의 OAuth를 이용한다면 Facebook의 사용자인지 인증하는 절차를 Facebook(Service Provider)이 처리
  • 하지만 OAuth의 근본 목적은 해당 사용자의 담벼락에 글을 쓸 수 있는 API나 친구 목록을 가져오는 API 등 API를 호출할 수 있는 권한이 있는 사용자인지 확인하는 것

• OAuth를 사용자 인증을 위한 방법으로 쓸 수 있지만 OpenID와 OAuth의 근본 목적은 다르다는 것을 알아야 함