쏭의 개발 블로그
OAuth 2.0 본문
💡 OAuth 2.0이란?
OAuth 2.0이란?
OAuth 2.0은 인증을 위한 개방형 표준 프로토콜입니다.
인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이라고 할 수 있습니다.
구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해, 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임받아 리소스 서버에서 제공하는 자원에 접근할 수 있도록 하는 표준 프로토콜을 제공합니다.
등장배경
과거에는 서비스(제3자 클라이언트)가 사용자를 대신하여 페이스북, 구글 등 다양한 플랫폼을 활용하는 기능을 만들 때, 사용자의 ID와 비밀번호를 직접 제공받아 서비스를 연동하는 방식이 사용되었습니다. 하지만 이 방식은 보안상 위험하고 관리 부담이 크다는 문제점을 가지고 있습니다.
문제점
- 사용자의 민감한 정보가 유출될 위험
- 서비스 제공자는 사용자의 정보를 안전하게 저장하고 관리해야하는 부담을 가짐
- 사용자가 권한을 취소하려면 비밀번호 변경이 필요
이러한 문제를 해결하기 위해 각 플랫폼은 자체적인 인증 방식을 개발했으나 표준화되지 않아 각각의 서비스와 개별적으로 연동해야하는 문제가 있었습니다.
OAuth는 이러한 문제를 해결하기 위해 등장하였고, 2012년 OAuth2.0이 등장하여 현재 가장 널리 사용되고 있습니다.
OAuth 2.0이 OAuth 1.0과 달라진점
- 기능을 단순화하고 확장성을 지원
- HTTPS 암호화가 필수이다.
- OAuth 1.0은 하나의 인증 방식만 제공했지만, 2.0은 다양한 인증 방식을 지원
- API 서버에서 인증 서버와 리소스 서버를 분리하여 보안을 강화
OAuth 구성요소
| 용어 | 간단한 설명 |
| Resource Owner | 사용자 |
| Authorization Server | 사용자의 동의를 받아서 권한을 부여하는 서버 |
| Resource Server | 리소스(Resource Owner의 개인정보)를 가지고 있는 서버 |
| Client | 자사 또는 개인이 만든 애플리케이션 서버 |
| Access Token | 자원에 대한 접근 권한을 Resource Owner가 인가했음을 나타내는 자격 증명 |
| Refresh Token | Access Token 만료시 이를 갱신하기 위한 용도로 사용하는 Token |
Resource Owner
서비스를 이용하면서 구글, 카카오, 페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자이다.
- 웹 서비스를 이용하려는 유저
- 자원(개인정보)을 소유하는 자
- 사용자
Resource Server (API 서버)
사용자의 개인정보를 가지고 있는 애플리케이션 회사 서버로, 구글, 페이스북, 트위터 등이 있다. 클라이언트는 Token을 이 서버로 넘겨 개인정보를 응답받을 수 있다. 구글, 페이스북, 카카오 등의 API 서버라고 생각하면 된다.
Authorization Server (인증 서버)
Resource Owner를 인증하고, Client에게 Access Token을 발급해주는 서버이다. 사용자는 이 서버로 ID, PW를 넘겨 Authorization Code를 발급받을 수 있으며, Client는 이 서버로 Authorization Code를 넘겨 Token을 발급받을 수 있다. 구글, 페이스북, 카카오 등의 인증 서버이다.
**Authorization Server와 Resource Server는 공식문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지, 하나의 서버로 구성할지는 개발자가 선택하기 나름이다.
Client
Resource Server 의 자원을 이용하고자 하는 서비스로, 일반적으로 우리가 개발하려는 서비스가 된다. Resource Server와 Authorization Server 입장에서는 서비스가 클라이언트이기 때문에 이러한 이름을 갖게 되었다.
Access Token
자원에 대한 접근 권한을 Resource Owner가 인가했음을 나타내는 자격 증명이다. 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료 기간이 있는 Token이라고 할 수 있다.
Refresh Token
Access Token 만료시 이를 갱신하기 위한 용도로 사용하는 Token으로, 일반적으로 Access Token보다 만료 기간이 길다. Client는 Authorization Server로부터 Access Token과 Refresh Token을 함께 부여받는다. Access Token은 비교적 짧은 만료시간을 가져 사용자는 로그인을 다시 시도해야 한다. 하지만, Refresh Token이 있으면 Access Token이 만료될 때 Refresh Token을 통해 Access Token을 재발급받아 재로그인할 필요가 없도록 한다.
OAuth 2.0 인증 과정(Flow)
Authorization Code Flow를 중심으로 한 OAuth 2.0 인증과정은 다음과 같다.
(1,2) 로그인 요청
Resource Owner(사용자)가 웹사이트의 소셜 로그인 버튼을 클릭하여 로그인을 요청한다. Client(서비스)는 사용자의 브라우저를 Authorization Server로 보낸다.
Client는 Authorization Server가 제공하는 Authorization URL에 response_type, client_id, redirect_uri, scope 등 매개변수를 쿼리 스트링으로 포함하여 보낸다.
- response_type : 반드시 code로 값을 설정
- client_id : 애플리케이션을 생성했을 때 발급받은 Client ID (ex. REST API 키)
- redirect_uri : 인증 처리 후 redirect 할 URI
- scope : 클라이언트가 부여받은 리소스 접근 권한
(3,4) 로그인 페이지 제공 + ID/PW 제공
Client가 빌드한 Authorization URL로 이동한 Resource Owner는 제공된 로그인 페이지에서 ID와 PW를 입력하여 인증한다.
(5,6) Authorization Code 발급 + Redirect URI로 리디렉트
인증이 성공하면 Authorization Server는 Redirect URI로 사용자를 리디렉션시킨다. Redirect URI는 Authorization Code를 쿼리 스트링에 포함하여 리디렉션한다. Authorization Code는 Client가 Access Token을 획득하기 위해 사용하는 임시코드로 1~10분 후 사라진다.
(7,8) Authorization Code와 Access Token 교환
Client는 Authorization Server에 Authorization Code를 전달하고 Access Token과 Refresh Token을 응답받는다. Access Token은 유출되어서는 안되므로 제 3자가 가로채지 못하도록 HTTPS 연결을 통해서만 사용될 수 있다.
(9) 접근 권한 생성 완료(로그인 성공)
리소스에 접근할 수 있는 권한이 서비스에 인가된다. 원하는 자원을 요청해서 사용할 수 있다.
(10,11,12,13) Access Token으로 리소스 접근
Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청한다. Client는 Resource Owner의 Access Token을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 서비스를 제공한다. 로그인 요청 시 설정했는 scope에 따라 접근할 수 있는 리소스가 결정된다.
📢 Authorization Code가 필요한 이유
Authorization Code 방식은 보안을 강화하기 위해 사용된다. 직접적으로 Access Token을 클라이언트에 전달하는 대신, Authorization Code를 발급받은 후 클라이언트가 이를 백엔드로 전달하고 백엔드가 Authorization Server에 요청하여 Access Token을 발급받는다.
- 보안 강화: 만약 Access Token을 바로 전달하면, Redirect URI를 통해 URL에 포함되어 클라이언트에 노출될 수 있다. Access Token은 민감한 정보이므로 브라우저에서 직접 노출되면 보안 위험이 발생한다.
- Authorization Code: 클라이언트는 Authorization Code를 받아 이를 백엔드로 전달하고, 백엔드는 Authorization Code를 이용해 Access Token을 요청한다. 이렇게 하면 Access Token이 백엔드 서버에서만 처리되고, 사용자 브라우저에 노출되지 않아서 보안이 강화된다.
💡 OAuth 2.0 Grant Types
OAuth 2.0 권한 부여 방식(Grant Types)
권한 부여란 클라이언트가 사용자를 대신해서 사용자의 승인 하에 Authorization Server로부터 권한을 부여받는 것이다. 권한 부여 방식은 다음과 같다.
(1) Authorization Code Grant | 권한 부여 승인 코드 방식
권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식
간편 로그인에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식이다. 서버 사이드 웹 애플리케이션에서 사용된다. Authorization Code를 발급받아 Access Token으로 교환하는 방식으로 Refresh Token 사용이 가능하다.
권한 부여 요청 시 response_type=code로 요청하며, 사용자가 로그인하면 권한 서버가 redirect_uri로 Authorization Code를 전달한다. 전달받은 Authorization Code는 권한 서버의 API를 통해 Access Token으로 교환된다.
(2) Implicit Grant | 암묵적 승인 방식
자격증명을 안전하게 저장하기 힘든 클라이언트에 최적화된 방식
SPA(JavaScript 기반 앱)나 모바일 앱과 같은 공개 클라이언트에서 사용되는 방식으로 보안에 취약하다. Authorization Code 없이 바로 Access Token이 발급되며, Refresh Token 사용이 불가능하다. Access Token이 URL로 바로 전달되므로 만료 기간을 짧게 설정하여 보안 위험을 줄일 필요가 있다.
클라이언트 인증(Client_secret 사용)이 없으며, response_type=token으로 요청하여 로그인 후 redirect_uri로 Access Token을 직접 전달받는다. 보안 문제로 현재는 잘 사용되지 않지만, 구현이 간단하여 일부 환경에서 여전히 사용된다.
(3) Resource Owner Password Crdentials Grant | 자원 소유자 자격증명 승인 방식
Username(ID), PW로 Access Token을 받는 방식
사용자의 ID와 비밀번호를 클라이언트가 직접 받아 Authorization Server에 전달하며 Access Token을 발급받는 방식이다. Refresh Token 사용이 가능하지만, 사용자의 자격 증명이 네트워크에 노출될 위험이 있다. 서버 애플리케이션에서만 사용되며, 보안에 취약하여 외부 프로그램에는 적용하면 안되는 방식이다.
(4) Client Credentials Grant | 클라이언트 자격증명 승인 방식
클라이언트의 자격증명만으로 Access Token을 획득하는 방식
주로 UI가 없는 서버 애플리케이션에서 사용되며, 클라이언트가 관리하는 리소스에 접근할 때 사용된다. Refresh Token은 사용할 수 없으며, 클라이언트가 자격 증명을 안정하게 보관할 수 있어야 한다. 이 방식은 클라이언트가 사용자 역할을 대신하여 서버 간 통신을 할 때 사용된다.
비교
| Grant Type | 사용 사례 | 특징 | Refresh Token |
| Authorization Code Grant | 간편 로그인, 서버 애플리케이션 | 사용자 승인 후 토큰 교환 | 가능 |
| Implicit Grant | SPA, 모바일 앱 | 바로 Access Token 발급 | 불가능 |
| Resource Owner Password Credentials | 서버 애플리케이션, 내부 클라이언트 | 사용자 ID/PW로 토큰 발급 | 가능 |
| Client Credentials Grant | 서버 간 통신, UI 없는 애플리케이션 | 클라이언트 자격증명으로 토큰 발급 | 불가능 |
참고자료
https://blog.naver.com/mds_datasecurity/222182943542
https://inpa.tistory.com/entry/WEB-📚-OAuth-20-개념-💯-정리
'Back-end' 카테고리의 다른 글
| JWT란 무엇인가? (+JWT 인증) (0) | 2025.04.05 |
|---|---|
| Soft Delete(논리 삭제)와 Hard Delete(물리 삭제) (0) | 2025.03.08 |
| XSS와 CSRF 공격 (2) | 2025.02.16 |
| HTTP method (GET&POST) (0) | 2023.01.31 |
| Redirect와 Forward (0) | 2023.01.31 |
