개발자라면 무조건 기본적으로 알아야한다는 OAuth의 개념부터 절차, 그리고 특징까지 자세히 공부하고 정리해보자!

OAuth란?

OAuth는 사용자가 자신의 민감 정보(아이디·비밀번호)를 직접 넘기지 않고도, 특정 서비스가 제한된 범위 내에서 내 계정에 접근할 수 있도록 해주는 ‘권한 위임(Authorization)’ 표준이다.

이해를 돕기 위해 비유로 설명하자면,

1. “문 열쇠” 대신 “방문증”을 준다고 생각해보자.
비밀번호나 API 키는 “집 전체를 열 수 있는 열쇠”와 같다. 그런데 단순히 특정 작업(방 한 개만 출입)만 필요할 때도 열쇠를 통째로 넘겨주는 것은 위험할 수 있다.
OAuth는 마치 “목적지(예: 욕실)만 출입할 수 있는 방문증”을 발급해주는 것과 비슷하다. 이렇게 방문증을 이용하면, 전체 집(계정 정보)에 대한 접근 권한을 주지 않고도 해당 방(특정 서비스 기능)에만 출입을 허용할 수 있다.

2) “○○로 로그인하기” 버튼
어떤 웹사이트에서 “Google로 로그인하기”나 “Facebook으로 로그인하기” 같은 버튼을 본 적이 있을 것이다. 이 버튼을 클릭하면 구글·페이스북 페이지로 이동해 로그인하고, 승인을 거쳐 돌아오게 된다.
이 과정을 통해 웹사이트는 구글·페이스북에서 발급받은 “한정된 권한의 토큰(Token)”만 받고, 실제 비밀번호나 전체 계정 접근 권한은 알 수 없다.

3) 사용자가 관리할 수 있는 권한
OAuth를 이용하면 사용자는 “이 앱이 내 구글 캘린더 일정을 읽기만 가능하도록” 제한을 걸 수 있다. 앱은 해당 범위 안에서만 접근할 수 있고, 사용자는 언제든 앱에 부여했던 권한을 철회(토큰 무효화)할 수 있다.

결론적으로 OAuth는 보안성을 높이고 서비스 간 연동이 편리해지는 장점이 있다.

---

OAuth의 주체와 흐름

OAuth의 핵심은 다양한 서비스가 안전하게 정보를 주고받는 것이다. 이를 위해 다음과 같은 주요 주체와 흐름이 존재한다.

OAuth의 주체

• 자원 소유자(Resource Owner): 사용자를 의미하며, 예를 들어 Google 계정을 소유한 사람이다.
• 클라이언트(Client): 사용자의 권한을 얻으려는 앱이나 웹사이트, 예를들어 "Google로 로그인하기" 기능을 제공하는 서비스
• 자원 서버(Resource Server): 사용자의 데이터를 보관하고 관리하는 서버, 예를 들어 Google이나 Facebook의 서버
• 인증 서버(Authorization Server): 권한 부여 과정을 담당하는 서버. 자원 서버와 함께 동작할 수도 있당.

OAuth의 흐름(Flow)

1. 사용자가 클라이언트(웹사이트/앱)에서 "○○로 로그인" 같은 작업을 시도함
2. 클라이언트는 사용자를 OAuth 제공(인증) 서버로 보냄
3. 사용자는 OAuth 서버에서 로그인(인증)하고, 클라이언트에게 허용할 권한 범위를 확인 후 승인함
4. OAuth 서버는 클라이언트에게 “토큰(Access Token)”을 발급함
5. 클라이언트는 발급받은 토큰을 자원 서버(Google, Facebook 등)에 제시해 필요한 정보를 얻거나 작업을 수행함

토큰(Access Token)의 특징

• 비밀번호 자체가 아니라, 임시로 허락된 권한만 담고 있는 문자열
• 만료 시간이 있거나, 사용자가 승인 철회할 수 있어 보안에 유리

---

OAuth 1.0 vs OAuth 2.0

1) OAuth 1.0의 한계

• 서명(Signature) 기반으로 매 요청마다 복잡한 파라미터와 해시 연산을 통해 요청을 검증해야 했다. 서명 처리 과정(파라미터 정렬, 인코딩, 해시 등)이 복잡했고, 구현 시 오류가 자주 발생했다.
• Request Token과 Access Token 발급 과정도 까다로워, 구현 난이도와 호환성 문제가 컸다.

2) OAuth 2.0의 개선점

• HTTPS를 통해 토큰을 보호함으로써, OAuth 1.0의 복잡한 서명 작업을 크게 단순화했다.
• 다양한 Grant Type(권한 부여 방식)을 도입해, 웹·모바일·서버 간 통신 등 여러 시나리오에 대응할 수 있게 되었다.
  • Authorization Code Grant: 서버 기반 웹앱이 주로 사용(코드 교환 방식)
  • Implicit Grant: SPA(단일 페이지 애플리케이션)에서 사용(현재는 보안 문제로 권장 안 함)
  • Resource Owner Password Credentials Grant: 사용자 아이디·비밀번호 직접 입력 상황(특수 경우)
  • Client Credentials Grant: 서버 간 통신 등 사용자가 직접 개입하지 않는 상황
• 자원 서버(Resource Server)와 인증 서버(Authorization Server)를 명확히 구분하여 역할이 더욱 분리되었다.
• 보안·확장성·개발 편의성이 모두 개선되어, 현재는 대부분 OAuth 2.0이 표준적으로 쓰이고 있다.

---

OAuth 2.0의 주요 Grant Type

OAuth 2.0은 상황에 따라 다른 인증 방식을 제공한다. 대표적인 Grant Type은 다음과 같다.

1. Authorization Code Grant

개념

• 서버 사이드(Web Server) 애플리케이션이 주로 사용하는, 가장 일반적이고 보안성이 높은 방식
• “사용자는 브라우저로 OAuth 서버에서 로그인/승인 → 인증 코드를 클라이언트(서버)로 넘김 → 클라이언트(서버)가 인증 코드를 가지고 최종 Access Token을 발급받음” 하는 단계로 진행
• 인증 코드(Authorization Code)를 한 번 더 거치는 구조라 직접 토큰이 유출될 위험이 줄어든다.

절차

1. 사용자가 클라이언트(웹사이트/앱)에서 “로그인/권한 부여” 요청을 시도
2. 클라이언트가 사용자를 OAuth 인증 서버로 리다이렉트
3. 사용자는 OAuth 인증 서버에서 로그인하고, 클라이언트에 허용할 권한 범위를 승인
4. 인증 서버는 인증 코드(Authorization Code)를 클라이언트에 돌려줌
5. 클라이언트는 받은 인증 코드와 Client Secret 등을 이용해 Access Token(때로는 Refresh Token 포함)을 발급받음
6. Access Token을 사용해 자원 서버(Resource Server)에서 사용자의 자원에 접근

특징

• 서버 측 애플리케이션에 적합 (Client Secret을 안전하게 보관할 수 있기 때문)
• Authorization Code를 한 번 더 거치는 구조라, 직접 토큰이 노출되지 않아 상대적으로 보안이 우수
• 최근에는 PKCE(Proof Key for Code Exchange)를 도입하여, 모바일/SPA 등 Public 클라이언트가 이 방식을 더 안전하게 사용할 수 있도록 지원

2. Implicit Grant

개념

• 과거 SPA 환경에서 서버 없이 동작하는 브라우저 자바스크립트 앱을 위해 제안된 방식
• 토큰이 URL 해시로 직접 전달되어, 노출 위험이 크고 보안 취약점이 많아 현재는 권장되지 않음
• 대부분 Authorization Code + PKCE를 대체 사용

절차

1. 사용자가 클라이언트(SPA 등)에서 “로그인/권한 부여” 요청
2. 클라이언트가 사용자를 OAuth 인증 서버로 리다이렉트
3. 사용자는 인증 서버에서 로그인·승인
4. 인증 서버는 브라우저 주소(URL 해시 파라미터 등)로 Access Token을 직접 넘겨줌
5. 클라이언트는 주소(URL)에서 Access Token을 추출해 사용

특징

• 서버 없이 동작하는 클라이언트(브라우저 JS 코드 등)를 위해 도입됐지만,
  URL 파라미터로 토큰이 노출되어 보안 위험이 커서 현재는 사실상 지양하는 추세
• 최신 권장 사항은 Authorization Code Grant + PKCE를 사용하는 방법

3. Resource Owner Password Credentials Grant (ROPC)

개념

• 사용자가 직접 자신의 아이디/비밀번호를 클라이언트(앱)에 입력해 그 정보를 OAuth 서버에 전달하고, Access Token을 발급받는 방식

절차

1. 사용자가 클라이언트(앱)에 ID/Password를 직접 입력
2. 클라이언트는 이 정보를 OAuth 인증 서버에 바로 전송
3. 인증 서버는 사용자를 인증하고, Access Token을 반환
4. 클라이언트가 Access Token을 사용해 자원에 접근

특징

• 보안에 취약: 클라이언트(앱)가 사용자 비밀번호를 직접 취급해야 하므로 위험
• ‘이미 클라이언트가 신뢰할 수 있는 앱’(사내 시스템 등)에서만 제한적으로 사용
• 일반 사용자 대상 서비스에는 거의 사용되지 않음

4. Client Credentials Grant

개념

• 사용자 개입이 없는 서버 간 통신이나 백엔드-백엔드 통신에 사용
• 클라이언트(서버)는 자신의 자격증명(Client ID/Secret)만으로 OAuth 서버에서 토큰을 발급받음

절차

1. 클라이언트(서버)가 자신의 Client ID/Secret을 인증 서버에 전송
2. 인증 서버가 검증 후 Access Token을 발급
3. 클라이언트가 Access Token을 사용해 필요한 자원에 접근

특징

• 사용자 인증이 아니라, 애플리케이션 자체가 자격증명을 통해 Access Token을 받음
  예) 마이크로서비스 간 통신, 백엔드 서버에서 다른 API 서버에 데이터 요청 등
• “사용자의 자원”보다는, “애플리케이션 소유 자원”에 접근하는 경우에 적합

5. Refresh Token Grant

개념

• 위의 Grant Type으로 Access Token을 발급받았을 때, 유효기간이 있는 토큰이 만료되면 Refresh Token을 사용해 새 Access Token을 발급받는 방식
• 실제로 인증(로그인) 절차를 매번 반복하지 않아도 되도록 만들어주는 메커니즘

절차

1. 사용자가 Access Token을 이미 받아 사용 중
2. 토큰 만료 직전(또는 만료 후) Refresh Token을 서버에 전송
3. 새로운 Access Token(필요시 새로운 Refresh Token도 함께)을 발급
   계속해서 사용자 자원에 접근 가능

특징

• 클라이언트가 “로그인 유지”를 위해 주기적으로 Refresh Token을 통해 Access Token을 재발급
• 만약 Refresh Token이 유출되면 위험하므로, 보관·사용 시 보안에 유의해야 함

---

왜 OAuth를 사용해야 할까?

1. 보안성

   • 계정 비밀번호를 직접 노출하지 않고, 토큰을 통해서만 접근 권한을 제한적으로 위임
   • 토큰은 만료 시간이 있거나, 사용자가 손쉽게 회수(권한 철회)할 수 있어 안전함

2. 확장성

   • 다양한 클라이언트 환경(서버, 모바일, 브라우저 등)에 맞춰 Grant Type을 골라 사용할 수 있다.
   • OAuth 2.0은 OpenID Connect 등 다른 표준과 결합해 인증(Authentication)까지 확장 가능하므로 서비스 간 연동이 유연해진다.

3. 편의성

   • “구글/페이스북/카카오로 로그인”처럼 사용자의 가입/로그인 절차를 단순화
   • 개발자 입장에서도, 표준화된 라이브러리를 통해 구현할 수 있어 편리함