카테고리 없음

OAuth 2.0

위시리 2025. 4. 28. 11:12

OAuth 2.0이란?

ID와 비밀번호 없이도 로그인할 수 있는 비밀

요즘 웹 서비스를 이용할 때 '네이버로 로그인', '구글로 로그인' 버튼을 자주 볼 수 있다. 별도로 회원가입을 하지 않아도, 신뢰할 수 있는 외부 서비스로 인증 과정을 대신 처리할 수 있기 때문이다. 이 모든 것은 바로 OAuth (Open Authorization) 덕분이다.

이번 글에서는 OAuth 2.0의 개념부터 등장 배경, 주요 구성 요소, 동작 원리까지 정리해보았다.

1. OAuth 2.0이란?

OAuth 2.0은 인증(Authentication)과 인가(Authorization)를 위한 개방형 표준 프로토콜이다.
쉽게 말해, 사용자로부터 ID/PW를 직접 받지 않고도, 제3자 애플리케이션(Client)이 사용자의 정보(Resource)에 접근할 수 있도록 권한을 위임하는 방법을 제공한다.

✅ 정리하면:

  • 사용자는 ID/PW를 애플리케이션에 직접 제공하지 않는다.
  • 대신 네이버, 구글, 카카오와 같은 신뢰할 수 있는 서비스의 인증 절차를 통해 로그인한다.
  • 애플리케이션은 최소한의 정보(예: 이메일, 이름 등)만 받아 사용자 인증을 대신한다.

예시

  • "네이버로 로그인하기"
  • "구글 계정으로 계속하기"
  • "카카오톡으로 시작하기"

2. OAuth가 등장한 배경

OAuth가 등장하기 전에는 다음과 같은 문제가 있었다.

  • A 서비스가 사용자 대신 네이버 데이터를 가져오려면 네이버 ID/PW를 직접 입력받아 저장해야 했다.
  • 이 방법은 사용자, A 서비스, 네이버 모두에게 심각한 보안 리스크를 초래했다.

주체 문제점

사용자 A 서비스에 네이버 ID/PW를 주는 것을 신뢰할 수 없음
A 서비스 민감한 정보를 보관해야 하고, 유출 시 책임 문제 발생
네이버 A 서비스를 신뢰할 수 없음

👉 이런 문제를 해결하기 위해 OAuth가 등장했다.
이제는 ID/PW를 넘기지 않고도, 안전하게 권한 위임을 할 수 있게 되었다.

3. OAuth 주요 구성 요소

 

Resource Owner 사용자 (자신의 개인정보 리소스를 소유하는 주체)
Client 사용자의 리소스에 접근하고자 하는 애플리케이션
Authorization Server 인증 및 권한 부여를 담당하는 서버 (ex. 구글 인증 서버)
Resource Server 실제 사용자 정보를 보관하는 서버 (ex. 구글, 네이버 등)
Access Token 권한이 부여되었음을 증명하는 토큰
Refresh Token Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위한 토큰

✅ 추가 설명

  • Access Token은 보통 유효기간이 짧다. (몇 분~몇 시간)
  • Refresh Token은 만료된 Access Token을 재발급받을 때 사용한다. 사용자에게 다시 로그인 요구 없이 원활한 사용 경험을 제공할 수 있다.

4. OAuth 2.0 동작 원리

OAuth 2.0이 실제로 동작하는 과정을 단계별로 살펴보았다.

(1) 웹 서비스 등록

먼저, 개발한 Client 서비스를 구글, 네이버 등의 OAuth Provider에 등록해야 한다.
이때 아래 정보가 발급된다.

  • Client ID
  • Client Secret
  • Redirect URI (인증 완료 후 사용자를 다시 보내줄 URI)

🚨 Client Secret은 외부에 절대 노출되어선 안 된다.

(2) 로그인 요청 (Authorization Request)

  • 사용자가 '구글로 로그인' 버튼을 누르면,
  • Client는 사용자의 브라우저를 Authorization Server로 보낸다.

이때 URL에는 다음과 같은 매개변수가 포함된다.

https://authorization-server.com/auth?
  response_type=code
  &client_id=클라이언트ID
  &redirect_uri=리다이렉트URI
  &scope=권한범위

파라미터 설명

response_type 항상 code
client_id 클라이언트 ID
redirect_uri 인증 완료 후 사용자를 보낼 URI
scope 요청하는 리소스 범위 (ex. 이메일 읽기, 프로필 읽기)

(3) 사용자 인증 및 승인

  • 사용자는 Authorization Server(구글, 네이버 등)에서 ID, PW를 입력해 인증한다.
  • 인증이 완료되면, Authorization Server는 사용자를 redirect_uri로 이동시키고, URL에 Authorization Code를 첨부한다.
https://example.com/callback?code=abcdefg12345

(4) Access Token 발급

  • Client는 받은 Authorization Code를 이용해 Authorization Server의 Token 엔드포인트로 요청을 보낸다.

요청 예시

POST /oauth/token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=abcdefg12345
&redirect_uri=https://example.com/callback
&client_id=클라이언트ID
&client_secret=클라이언트시크릿
  • 성공 시, Access Token (필요에 따라 Refresh Token도)을 받게 된다.

(5) 리소스 접근

  • 이제 Client는 발급받은 Access Token을 이용해 Resource Server에 접근할 수 있다.
GET /user/profile
Authorization: Bearer access_token_value
  • 이렇게 해서 사용자의 리소스를 안전하게 사용할 수 있다.

추가로 알아두면 좋은 내용 🔥

  • HTTPS 필수
    Access Token은 민감한 정보이기 때문에, 항상 HTTPS 통신을 통해 주고받아야 한다.
  • Scope 조정
    OAuth 요청 시 scope를 통해 필요한 권한만 요청해야 한다.
    예를 들어 단순 로그인만 필요한데 사용자의 연락처 접근을 요청하면 사용자 신뢰를 잃을 수 있다.
  • OAuth는 인증(Authentication) 프로토콜이 아님
    OAuth 자체는 **인가(Authorization)**를 목적으로 만들어졌다.
    인증(Authentication)을 해결하려면 OAuth를 기반으로 한 **OpenID Connect (OIDC)**를 사용해야 한다.
  • Implicit Grant는 점점 사용되지 않음
    OAuth 2.0에는 여러 종류의 Grant Type이 있는데,
    Implicit Grant는 보안상의 이유로 최근에는 거의 사용되지 않고, 대신 Authorization Code Flow + PKCE 방식이 많이 사용된다. (특히 모바일, SPA 환경)

 

마치며

OAuth 2.0 덕분에 우리는 별도로 비밀번호를 입력하거나 저장하지 않고도 다양한 외부 애플리케이션과 안전하게 연결할 수 있게 되었다.
물론 올바른 설정과 보안 수칙을 지키는 것이 전제이다.
이제 '구글로 로그인', '네이버로 로그인' 버튼을 볼 때마다, 그 뒤에서 돌아가는 이 멋진 프로토콜을 떠올려보자.

저작자표시 (새창열림)