OAuth란 무엇인가? (인증에 대하여)

티스토리 API 어떻게 써야하지

  간단한 프로젝트를 하나 시작하면서 티스토리 API를 사용해야했다. API를 이용해서 내 블로그에 올라온 글을 가져와야하는데, 인증에 대한 기초가 없어서 이용방법이 이해가 되지 않았다. 어찌저찌해서 Access token을 받아 API를 사용할 수 있게 되었지만, 어떤 과정으로 사용이 가능하게 되었는지 확인해보기로 했다.

  OAuth의 동작에 대해 공부를 시작하고나니 궁금한 내용이 꼬리에 꼬리를 물어 많은 내용이 담기게 되었다. 인증에 대한 기본 지식이 없어, 여러 자료를 토대로 나름의 순서로 재구성해보았다.

 

1. 기본 인증 동작

1-1) 인증 방식

• 웹 서비스에서 가장 많이 사용되는 통신 방식은 HTTP
• 보통 인증 과정에서 HTTP의 헤더에 인증 수단을 넣어 서비스 요청을 보냄

 

1-2) 계정정보를 포함하는 방식

• 동작
  • 헤더에 계정정보를 포함시켜 보내는 방식
• 장점
  • 가장 간단한 방법
• 단점
  • 암호화가 전혀 되지 않으므로 보안이 0임
  • 매 요청마다 계정정보를 확인하여 인증해야함

 

1-3) 세션/쿠키 방식

• 동작
  • 사용자 인증 후 session id 발급
  • 사용자는 session id를 쿠키에 저장
  • 요청마다 session id를 헤더에 실어 인증
  • 서버는 session id와 사용자 정보를 저장소에 저장해야함

출처 : [6] https://tansfil.tistory.com/58?category=475681

• 장점
  • session id를 이용하여 계정정보보다 안전함
  • 계정정보를 대신 session id로 회원을 식별하여 인증이 간단해짐
• 단점
  • session id를 탈취하면 해당 사용자로 식별되어 보안이 취약함

 

2. 토근기반 인증

2-1) Access Token

• JWT
  
  • JWT(Json Web Token) : 인증에 필요한 정보들을 암호화시킨 토큰 (Access Token)
  • JWT의 구성
    - Header : 암호화 방식, 타입
    - Payload : 서버에 보낼 user id, 유효기간
    - Signature : Base64로 인코딩한 Header/Payload에 Secret key(비밀키)를 더한 후 서명
  • 인코딩(16진수)한 Header/Payload는 디코딩할 수 있으나, Secret key 없이 Signature를 확인할 수 없음
  • Signature를 복호화하여 Header와 Payload의 위변조를 검증

출처 : [4] https://velopert.com/2389

서명?
1. 공개키(public key) vs 비밀키(private key)
- 공개키 : 모든 사람들이 접근할 수 있는 키
- 비밀키 : 각 사용자만 지니며, 공개되어서는 안되는 키
2. 대칭키 방식 vs 비대칭키 방식
- 대칭키 방식 : 암호화/복호화에 사용되는 키가 동일 (키를 배송해야하는 문제)
- 비대칭키 방식 : 암호화/복호화에 사용되는 키가 다름 (암호화/복호화가 되는 공개키/비밀키 쌍이 존재)
3. 공개키로 암호화 vs 비밀키로 암호화
- 공개키로 암호화 : Data 보안에 중심, 쌍을 이루는 비밀키를 가진 유저만 복호화 가능
- 비밀키로 암호화 : 인증에 중심, 내 비밀키와 쌍을 이루는 공개키를 가진 유저(이 방법이 전자서명)

-> 여기서 나오는 서명과는 연관이 없는듯.... (암호화/복호화 모두 서버가 담당)

• 동작
  • 사용자를 확인 후 고유한 ID를 부여하여, 기타 정보와 함께 JWT의 Payload에 추가
  • JWT의 유효기간 설정
  • 비밀키를 이용해 Access token(JWT) 발급
  • 사용자는 Access token을 저장하고, 요청마다 토큰을 헤더에 실어 보냄
  • 서버는 Signature를 복호화하여 조작 여부와 유효기간 확인
  • 검증되면 Payload를 디코딩하여 사용자 ID에 맞는 데이터로 응답

출처 : [6] https://tansfil.tistory.com/58?category=475681

• 장점
  • 서버는 사용자 정보를 저장소가 아닌 토큰으로 발급하여 저장소 관리가 필요 없음
  • 이는 별도의 저장소에 상태를 저장하지 않는 Stateless 서버를 만들 때 강점
  • 서버 확장/유지보수에 유리
• 단점
  • 탈취될 경우, 유효기간까지 악용될 수 있음
    - 세션/쿠키 방식에서는 악의적 사용이 확인되면 해당 세션을 제거할 수 있음
  • Payload가 암호화되지 않으므로 정보가 제한적
    - 세션/쿠키 방식은 사용자 정보가 서버 저장소에 안전하게 보관(?)
  • 세션/쿠기 방식에 비해 JWT 길이가 길어 요청에 따라 서버의 자원이 더 소모됨

 

2-2) Access token + Refresh token

• 문제 정의
  • Access token이 탈취될 경우, 유효기간동안 사용자 정보에 접근이 가능하여 보안이 취약함
  • 유효기간이 짧아질 경우, 사용자의 로그인이 빈번해져서 불편함
• Refresh token
  • Access token과 같이 JWT 형태
  • 첫 로그인시 Access token과 함께 발급
  • 긴 유효기간(보통 2주라고 함)을 가지며, Access token이 만료될 시 새로 발급해주는 key 역할
• 동작
  • 사용자 확인 후, Access token과 Refresh token을 함께 발급
  • 사용자는 요청시 Access token으로 인증에 사용, Refresh token은 안전한 저장소에 보관
  • Access token이 만료되면, 사용자는 Access token과 Refresh token을 함께 전송
  • 서버는 Access token의 조작을 확인 후, 서버 저장소에 저장된 Refresh token을 비교하여 만료 확인 후 Access token 발급

출처 : [10] https://tansfil.tistory.com/59?category=475681

• 장점
  • Access token만 사용할 때보다 안전함
• 단점
  • 구현이 복잡해짐
  • 만료가 빈번해질수록 서버에 대한 요청이 빈번해져 서버 자원 소모

 

3. OAuth

3-1) OAuth란

• 정의
  • Access token 혹은 Access token + Refresh token 활용
  • 외부 서비스의 인증 및 권한 부여를 관리하는 범용 프로토콜
  • OAuth는 Open Authentication/Authorization으로, 인증+권한을 의미
• 특징
  • 권한
    - 사용자의 권한에 따라 접근 데이터가 다르도록 설정이 가능
  • 프로토콜
    - 프로그램이 아닌 일종의 규격 (티스토리는 OAuth라는 규격에 맞춰 인증/권한을 대행 관리)
  • 외부 서비스
    - 우리가 만들고 있는 서비스를 나타내며, OAuth는 외부 서비스를 위한 서비스로 인증/권한부여 관리를 대행

 

3-2) OAuth 1.0a

• 특징
  • Access token 활용
  • Third party 어플리케이션에서 API를 사용할 때 사용자 정보가 노출되지 않음
  • 인증+권한을 부여할 수 있음 (Open ID는 인증만 가능)
  • 필요한 API에만 제한적으로 접근하도록 권한 제어 + 권한 취소가 가능
  • 계정정보(패스워드)가 변경되어도 인증토큰은 유지됨
• 구성
  • 동작의 참여자가 셋이므로 3-legged OAuth라고도 함
  • Service Provider
    - 인증 및 API 제공 역할 (트위터)
  • Consumer
    - Service Provider의 API를 활용하는 어플리케이션 (트위터 단말 어플리케이션)
  • User
    - Consumer 이용자 (사용자)
• 동작
  • User가 Consumer를 이용
  • Consumer는 Service Provider의 로그인 화면으로 redirect
  • 로그인 성공시 Consumer로 redirect
  • 동시에 Consumer는 Access token을 받아 User의 데이터에 접근하는 API 사용 가능

출처 : [7] https://i2.wp.com/earlybird.kr/wp-content/uploads/2013/02/oauth2_triangle2.png

• Request token
  • Consumer가 Service Provider에 Access token을 받는 과정에서 사용
  • 암호화 등 과정이 복잡함

 

3-3) OAuth 2.0

• 특징
  • Access token + Refresh token 활용
  • 1.0a에서는 모바일에서의 사용성 문제
  • 1.0a에서는 signature 생성 등 개발이 복잡하고 CPU 소모가 많음
  • 기능과 규모의 확장성 지원을 위해 만들어짐
• 개선된 부분
  • 간단해짐
    - 1.0a에서는 https가 필수가 아니었으므로 signature를 생성해야했음
    - 따라서, API 테스트에 curl 등 사용이 어려움
    - OAuth 2.0에서는 Bearer 토큰 인증 방식으로 signature가 필요없어 curl 등으로 API 테스트 사용 가능
    - 이를 통해 직관적인 방법으로 사용이 가능하여 문서화하고 개발이 가능
  • 다양한 인증 방법 지원
    - 1.0a는 HMAC를 이용한 한 가지 인증 방식을 제공
    - 2.0은 시나리오별 여러 인증 방식을 제공하여 웹브라우저, 모바일 등 다양한 시나리오에 대응 가능
  • 대형 서비스로의 확장성 지원
    - 큰 서비스를 위해 인증 서버 분리 및 다중화가 필요
    - 2.0에서는 API 서비스 서버와 인증 서버를 구분하여 다중화 등에 대한 고려가 되어있음
• 용어
  • Resource Owner
    - 사용자
  • Resource Server
    - API 서버
  • Authorization Server
    - 인증 서버 (API 서버와 같을 수 있음)
  • Client
    - Third-party 어플리케이션
• 인증방식
  • OAuth 2.0이 지원하는 인증방식은 clinet 종류와 시나리오에 따라 4가지로 나뉨
  • 그러나 Authorization Code Grant와 Implicit Grant외에는 2-legged로 많이 사용되지 않음
  • Client의 종류
    - Confidnetial Client : 웹 서버가 API를 호출하는 경우 등과 같이 client 증명서(client_secret)을 안전하게 보관할 수 있는 client
    - Public Client : 브라우저기반 어플리케이션이나 모바일 어플리케이션처럼 client 증명서를 안전하게 보관할 수 없는 client로, redirect_uri를 통해 client를 인증
• Authorization Code Grant
  • 웹 서버에서 API를 호출하는 등의 시나리오
  • Confidential client가 사용하는 방식
  • server-side 코드가 필요한 인증 방식으로, 인증 과정에서 client_secret이 필요
  • 로그인시 페이지 URL에 response_type=code라고 넘김
• Implicit Grant
  • OAuth 1.0a와 가장 비슷한 인증 방식
  • Public client인 브라우저 기반 어플리케이션(javascript application)이나 모바일 어플리케이션에서 사용
  • client 증명서가 필요없으며, 가장 많이 사용되는 방식이라고 함
  • 로그인시 페이지 URL에 response_type=token이라고 넘김
• Authorization Code Grant를 사용한 동작
  • Resource Owner가 Client에 인증 요청
  • Clinet가 Resource Owner에게 인증 url로 redirect
  • 로그인이 완료되면 권한증서(Authorization Grant)를 url에 실어 Client로 전송
  • Clinet는 권한증서를 Authorization Server로 보내고, Access token, Refresh token, 유저 정보를 발급
  • Client는 Access Token을 DB에 저장하거나 Resource Owner에게 넘김
  • 자원 필요시, Access Token을 담아 Resource Server에 요청
  • 이후 과정은 Access Token + Refresh Token 과정과 동일

출처 : [9] https://developers.payco.com/guide/development/start

• 다양한 토큰 지원 (Access token)
  • 기본적으로 암호화하지 않은 Bearer 토큰을 주고 받는 것으로 인증
  • 기본적으로 HTTPS를 사용하므로, 보안은 HTTPS 암호화에 의존
  • 복잡한 signature 생성이 필요없어 API 테스트에 용이

 

마무리

  인증과 관련된 모든 내용을 이해한 것은 아니지만, 꽤 시간을 들여 이해도를 높일 수 있었다. 외부 API를 사용할 때 서버에서 갖추어야할 게 많다는 것을 알았고, 토큰 만료에 대해 재발급 받는 과정도 꽤 복잡한 듯 하다.

  무엇보다 이러한 인증 방식이 마이크로서비스와 어울린다는 생각이 들었다. OAuth 2.0을 보면 역할이 세분화되어 나누어져있고, 1.0a에서도 트위터의 모바일 앱이 third-party 앱으로 구분되어 API 이용자로 취급된다.

  아직 풀리지 않은 것은 HTTPS와 티스토리 Access token이다. HTTP에 대해서 제대로 공부하지 않아 OAuth 2.0에서 HTTPS를 사용할 때 달라지는 차이점이 명확하지 않다. 이 부분에 대해서도 공부를 해야겠다. 그리고 티스토리 테스트중에 발급받은 Accces token을 며칠 째 사용해도 정상동작하는 것에 대해 만료시간이 없는 것인지 아직 파악하지 못했다. 문서에 따르면 Authorization code는 1시간 후 만료인데, Access token에 대해서는 유효기간에 대한 설명이 없다. 만들고자하는 서비스는 우선 토큰 만료를 고려하지 않을 예정이며, 문제가 생길 시 다시 Access token을 발급받는 내용을 추가해야겠다!

 

참조

[1] https://chickenpaella.tistory.com/40

전자 서명이란?

[2] https://liveyourit.tistory.com/183

[암호학] 대칭키 vs 공개키(비대칭키) 암호화 차이

[3] https://blog.naver.com/PostView.naver?blogId=chodahi&logNo=221385524980 

공개키(Public Key) and 개인키( Private Key)

[4] https://velopert.com/2389

[JWT] JSON Web Token 소개 및 구조 | VELOPERT.LOG

[5] https://meetup.toast.com/posts/239

JWT를 소개합니다. : NHN Cloud Meetup

[6] https://tansfil.tistory.com/58?category=475681 

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT)

[7] https://www.icatpark.com/entry/OAuth-20-%EC%9D%B4%ED%95%B4

OAuth 2.0 이해

[8] https://d2.naver.com/helloworld/24942

[9] https://developers.payco.com/guide/development/start

PAYCO 로그인 및 PAYCO 바로가입 개발 가이드

[10] https://tansfil.tistory.com/59?category=475681 

쉽게 알아보는 서버 인증 2편(Access Token + Refresh Token)