OAuth1.0 vs OAuth2.0

LDB·2025년 1월 4일

OAuth1.0 OAuth2.0 인증

CS 지식

목록 보기

1/7

Oauth란?

OAuth란 무엇인가? 흔히 타 사이트에서 보던 SNS로그인 이것들이 바로 OAuth 인증 프로토콜이다. 좀 더 자세히 이야기하자면 현재 사용되고 있는 SNS인증은 OAuth2.0 방식이다.

(해당 화면은 사람인 로그인 페이지 화면으로 구글, 네이버, 카카오등 다양한 SNS 로고를 확인 할 수 있다.)

OAuth는 Open Authorization, Open Authentication의 약자로 유저의 비밀번호를 third party앱에 제공 없이 인증,인가를 할 수 있는 오픈 스탠다드 프로토콜을 말한다.

나오게 된 계기

인증은 기본적으로 아이디와 비밀번호를 사용하여 로그인을 하는 것이 일반적이었지만 이방식은 유저의 비밀번호가 노출될 가능성이 컸다. 기존에도 거론된 문제였지만 외부 사이트와 인증깁반 데이터를 연동할 때 인증방식의 표준이 없어서 사용하지 않고 있었다. 하지만 이를 OAuth의 인증은 API를 제공하는 서버에 진행했고, 유저의 인증여부를 Access Token발급으로 증명했고 발급된 Token으로 리소스서버로 부터 정보를 가져와 서로 통신하면서 안전하고 쉽게 사용할 수 있게 되었다.

Token을 사용하면

다른 서비스의 ID / Password가 아니라는 장점이 있다.
다른 서비스가 가지고 있는 모든 부분이 아닌 그중에 나의 서비스가 꼭 필요한 기능을 부분적으로 허용한다.

정리하지면 OAuth는 인증은 유저가 직접하고 권한은 서비스가 갖게하는 것이다.

인증(authentication) : 유저가 누구인지 확인하는 절차로 회원가입 및 로그인 이라고 할 수 있다.
예시 : 가게에서 나의 인적사항을 입력하고 대기열에 등록

인가(authorization) : 유저에 대한 권한을 허락하는 것
예시 : 가게에 들어가기 위해 본인의 입장순서를 보여주는 행위

OAuth1.0 개요

(상단의 이미지는 OAuth1.0의 과정을 간략하게 작성 한 것이다.)

OAuth1.0의 과정

Resource Owner즉 사용자가 Client에게 접근 요청을 보낸다.
Client는 Server에게 접근 의도가 있음을 API로 요청을 보낸다 그런 후 Server는 Client에게 어디서 인증을 하고 Client에 대한 인가 작업을 할 수 있는지 응답을 전송한다.
Server로부터 응답받은 Client는 사용자에게 302 리디렉트 또는 비슷한 웹사이트로 보내게 된다.
예를들어 SNS로그인은 이메일주소 혹은 아이디 그리고 비밀번호를 입력하는 인증을 거치고 여러가지 플로우를 탄 후에 마지막으로 어플리케이션에 대한 권한을 인가하게 된다.
인가 작업 종료 후 Server는 마찬가지로 302 리디렉트 나 웹 기반 리디렉트를 사용하여 받은 인증 값을 Client에게 넘겨준다.
Client는 인증 값을 받아서 API호출을 통해 server로 부터 토큰을 받는다.
Client는 내 리소스에 접근시 사용자를 대신해 어떤 서비스를 발급 받은 토큰을 사용해서 리소스에 접근한다.

OAuth1.0의 문제점

scope에 대한 개념이 없다.
OAuth Server의 어느 서비스 까지 권한이 있는지 세밀하게 제어하기가 어렵다.

유효기간에 대한 개념이 부족
OAuth1.0은 발급받은 토큰의 유효시간 개념이 상세히 명세가 되어있지 않았다. 이로 인해 토큰이 무제한으로 유효할 수 있거나, 만료 및 갱신되지 않을 수 있다. 즉 보안상에 위험이 있다.

클라이언트 구현이 복잡
암호화 및 서명 절처, 요청 및 응답의 암호화 방식, Nonce 및 Timestamp 사용 등의 기술적인 요구사항들이 클라이언트 개발자에게 부담을 준다.
이렇게 되면 애플리케이션 개발 및 유지보수가 어려워지고 오류 발생 가능성을 높일 수 있다.

역할이 명확하게 나눠져 있지 않다.
OAuth Server의 역할은 Resource Owner 인증, 인가 토큰 발급, 보호된 리소스 관리 등 역할의 개념이 모호하다.

사용환경이 제한적이다.
OAuth1.0은 웹 브라우저 환경에 최적화 되어있어서 모바일에서의 지원이 부족하다.

OAuth2.0 개요

이러한 문제를 해결하기 위해 OAuth2.0이 출시하게 되었다.

개선된 점들

scope 기능 추가
scope은 사전적의미로 범위라는 뜻인데 말그대로 발급 받은 토큰이 얼만큼의 접근 범위가 있는지를 나타낼 수 있게 되었다.

클라이언트 복잡성 간소화
OAuth1.0에서도 보안에 문제가 있음을 인지하고 보안성을 강화하기 위해 암호학적 보안책을 사용했다. 보호를 받기위해 signature라는 것을 만들었는데 간단한 post요청에도 매번 동일한 signature을 만들었다.
이러한 문제를 해결하기위해 Bearer token + TLS를 사용해서 극복했다.

Bearer token
"Bearer"는 소유자라는 뜻인데, "이 토큰의 소유자에게 권한을 부여해줘"라는 의미로 이름을 붙였다.
해당 토큰을 소유를 하고 있는 것만으로도 이 토큰에 대한 사용권한이 있음을 인정해주는 토큰을 말한다.
토큰을 소유하는 것만으로도 권한이 생기기 때문에, 2.0에서는 TLS, 가장 대표적으로 Https를 강제하게 된다.

Refresh token 도입
OAuth1.0 에서는 토큰의 유효기간이 정말 길었기에 토큰이 탈취되면 긴시간 동안 어뷰징을 할 수 있는 가능성이 있다.
2.0에서는 이러한 문제를 해결하기 위해 Refresh Token이라는 개념을 새로 만들었다. 리소스 접근시에는 짧은 유효기간의 Access Token을 사용하고 Refresh Token으로 재발급을 받아서 사용한다.

만약 Access Token이 탈취 당해도 Access Token이 짧은 시간만 어뷰징을 할 수 있기 때문에 보안성을 개선할 수 있다.

Auth와 Resource 서버 분리
OAuth1.0에서는 Server가 인증, 리소스 관리를 전부 했지만 OAuth2.0에서는 인증 서버(authorization)와 리소스 서버(Resource) 두 개로 나누었다. 두 개의 역할을 확실히 분리함으로써 조금 더 개선된 아키텍쳐를 만들 수 있게 되었다.

Grant
OAuth1.0은 사용환경이 웹 브라우저에 최적화 되어있어서 환경이 제한적이라고 이야기했는데, 이는 모바일과 같은 환경에서 사용하기가 어렵다. 게다가 현재 여러 서비스및 구축에선 Server-to-Server Interaction(서버 간 상호작용)이 필수적으로 요구하게 된다. 그렇기에 OAuth2.0은 Grant라는 개념을 추가했는데 Grant는 여러가지 사용 환경에 대해 허가를 받는 유형이라고 생각하면 되겠다.

Grant 유형

1. Authorization Code Grant (인가 코드 방식)

Resource Owner에게 사용 허락을 받았다는 증서인 권한 코드 (Authorization Code)를 가지고 Access Token을 요청하는 방식이다.
구현방식은 복잡하지만 좀 더 신뢰성이 있고 Access Token의 시간이 좀 더 길고, 다시 액세스 토큰을 발급받을 수 있는 Refresh Token을 함께 발급한다.

2. Implicit Grant (암묵적 승인 방식)

추가적인 절차 없이 Resource Owner가 인증 및 허가를 하면 바로 Access Token이 발급되는 방식이다 대신에 Access Token의 유효시간이 짧은 편이다.

3. Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식)

직접적으로 유저의 아이디와 비밀번호를 받아서 클라이언트가 요청을 하는 방식이다 다만 직접적으로 유저정보가 가는만큼 유저가 가지고 있는 기기의 OS와 같은 신뢰가 높은 안전한 환경에서만 사용이 가능하다. 그렇기에 특수한 상황을 제외하고는 일반적으로 권장되지 않는다.

4. Client Credentials Grant (클라이언트 자격증명 승인 방식)

Client와 Resource Onwer가 같은 주체일 때, 복잡한 플로우를 가져가기보다 직접적으로 API 호출을 통해서 토큰을 발급을 받을 수 있는 방식이다 이 방법은 자격증명이 안전하게 보관되는 클라이언트에서만 사용되어야 하며 Refresh Token은 사용할 수 없다.