학습 내용

OAuth

개요

OAuth: 개방형 인증 및 권한 부여 프로토콜
쇼핑몰 웹 사이트에 로그인 할 때
이미 사용 중인 나의 구글 계정을 이용해서
별도 회원가입 없이, 쇼핑몰 웹 사이트를 이용할 수 있다.
이 시스템을 Single-Sign-On(SSO) 라고 부른다.

하지만, SSO를 사용하면 보안상 취약한 점이 발생한다.
만약 구글 계정을 이용해 다른 애플리케이션을 이용할 때,
구글 계정 탈취의 위험성이 있다.

그래서 SSO 시스템에서 발생할 수 있는 보안상의 문제를 해결하기 위해 OAuth가 등장했다.
이전에는 다른 서비스의 계정 정보를 직접 입력해야 했는데,
OAuth는 인증을 위한 정보를 제공하고 접근 권한을 설정하여,
사용자의 비밀번호가 제3자에게 노출되는 것을 막는다.
또한 OAuth를 통해 사용자의 정보를 제공하는 과정에서도 보안에 강화되어 있다.

OAuth 방식은 사용자가 다른 애플리케이션에서 로그인할 때,
사용자의 로그인 정보(아이디와 비밀번호)를 제공하는 대신,
인증 서버에서 토큰이라는 것을 발급하여 해당 애플리케이션이나 웹사이트에 전달한다.

이 토큰을 통해 애플리케이션은 사용자의 인증을 확인할 수 있으며,
사용자의 계정 정보를 공유하지 않으므로 보안상 안전한 방식이다.
즉, OAuth는 인증 정보를 제공하는 대신 인증을 위한 토큰을 전달함으로써,
보안성을 유지하면서도 다른 애플리케이션에서 서비스를 이용할 수 있는 기술이다.

작동 메커니즘

OAuth의 주체

용어 정리를 해보자.

• Resource Owner
  사용자는 Resource Owner이다.(OAuth 인증을 통해 로그인하는)
• Resource Server & Authorization Server
  새로 사용할 서비스를 Application라 하자.
  이미 사용 중인 서비스(Naver, Kakao, Google 등)의 서버 중,
  사용자의 정보를 저장하고 있는 서버를 특정해서 Resource Server라고 한다.
  이미 사용 중인 서비스의 서버 중 인증을 담당하는 서버를 Authorization Server라고 한다.
• Application
  사용자가 소셜 로그인을 활용해 이용하고자 하는 새로운 서비스를 Application라고 하자.
  경우에 따라서 Applicaiton을 Client와 Server로 세분화해서 지칭하기도 한다.

OAuth 인증 방식의 종류와 흐름

3가지가 있다.
*Grant Type: Authorization Server에서 Access Token을 받아오는 방식이다.

• Implicit Grant Type: 보안성이 조금 떨어짐.

1. 사이트 접속(사용자 -> 앱)
   사용자가 App에 접속

2. 인증 요청(앱 -> 인증 서버)
   App에서 Authorization Server로 인증 요청을 보낸다.

3. 인증 확인(인증 서버 -> 앱)
   Authorization Server는 유효한 인증 요청인지 확인한 후 엑세스 토큰을 발급한다.

4. 엑세스 토큰 전달(인증 서버 -> 앱)
   Authorization Server에서 App으로 엑세스 토큰을 전달한다.

5. 엑세스 토큰 전달(앱 -> 인증 서버)
   App은 발급받은 엑세스 토큰을 담아 Resource Server로 사용자의 정보를 요청한다.

6. 엑세스 토큰 확인(인증 서버)
   Resource Server는 App에서 전달받은 엑세스 토큰이 유효한 토큰인지 확인한다.

7. 사용자 정보 전달(인증 서버 -> 앱)
   유효한 토큰이라면, App이 요청한 사용자의 정보를 전달한다.

8. Authorization Code Grant Type: Implicit에서 인증 단계를 한 단계 추가한 것.(Authorization Code를 이용해 인증을 한 단계 추가)

9. Refresh Token Grant Type: Refresh Token을 사용.

장점

좋은 사용자 경험(쉽고 안전한 서비스 이용)

• 사용자는 OAuth를 통해 특정 사이트에 아이디, 비밀번호, 이름, 전화번호 등의 정보를 일일이 입력하지 않아도 클릭 몇 번 만으로 손쉽게 가입할 수 있어 편리하다.
• 정보를 해당 서비스에 직접 노출하는 것이 아니기 때문에 직접 가입하는 것보다 더 안전하다.
• Application의 입장에서도 회원의 정보를 직접 가지고 있음으로 인해서 발생할 수 있는 회원 정보 유출의 위험성에서 부담을 낮출 수 있다.

권한 영역의 설정

• OAuth 인증을 허가한다고 해서 새로운 서비스가 사용 중이던 서비스의 모든 정보에 접근이 가능한 것은 아니다. 사용자는 원하는 정보에만 접근을 허락할 수 있어 보다 더 안전하다.
• OAuth 설정 페이지에서는 Application에서 필요한 정보를 선택할 수 있다. 사용자는 이 중 원하는 정보만 선택적으로 제공할 수 있다.

종합퀴즈 리뷰

1. 쿠키에 대한 설명

• MaxAge 또는 Expires 옵션이 설정되는 쿠키의 경우 설정된 시간이 지난 이후 자동으로 제거된다.
  해당 옵션이 없는 경우, 지정하지 않으면 쿠키가 세션 쿠키가 된다.
  클라이언트가 종료되면, 세션이 종료되고, 그 후에 세션 쿠키가 제거 된다.
• httpOnly 옵션을 사용하면, 자바스크립트를 이용해서 쿠키에 접근할 수 없다.
• sameSite=none은 모든 요청에 대해 쿠키를 주고받을 수 있지만,
  Secure 옵션, 즉 HTTPS 프로토콜을 사용하는 것이 필수적이다.
• 요청하는 서버의 도메인, 경로, sameSite 등의 조건이 맞아떨어질 경우 같이 전송된다.

2. session 기반 인증 방식
   세션은 보통 하나의 서버에서만 접속 상태를 저장한다.
   여러 개의 서버에서 같은 세션 데이터에 접근하려고 하면,
   session clustering 혹은 공통 session store를 사용해야 하는 번거로움이 있기 때문에 유리하지 않다.
3. 세션 대신 토큰 기반 인증의 사용을 고려하는 이유
   서버의 부담을 덜어주기 위해서.
   여러 개의 서버를 사용하는 서비스를 운영할 때.
   앱의 확장을 고려할 때.

세션
세션은 서버측에서 저장/관리하기 때문에 상대적으로 온전한 상태 유지에 유리하다.
하지만 여전히 공격의 위험이 있다.
따라서, 유효기간, HttpOnly, Secure 옵션 등을 주어 쿠키에 저장한다.

토큰
토큰은 웹 브라우저 측(local storage, 혹은 쿠키 등)에 저장된다.
위험에 노출될 가능성이 더 큽니다.

이런 경우를 대비해 토큰에는 민감한 정보를 담지 않는다.
또한, 유효기간을 짧게 설정해 공격에 노출될 수 있는 시간을 최소화한다.
하지만 짧은 주기로 토큰이 무효화되면 서비스 사용자는 계속 로그인을 해줘야 하는 번거로움이 있다.
애초에 로그인(인증)시 refresh token이라는 것을 추가적으로 발급한다.

refresh token은 access token 보다 긴 유효기간을 가졌으며 최대한 안전한 곳에 저장된다.
기존의 토큰이 만료되거나 변질되면 refresh token을 통해 토큰을 재발급한다.

=> 따라서, 토큰 기반 인증이 세션 기반 인증에 비해 더 안전하다고 볼 수 없다.