본문 바로가기
Development

OAuth2.0 동작 흐름 알아보기

by 파크인포 2024. 10. 20.

OAuth2.0은 애플리케이션과 같은 서비스에서 사용자 자격 증명을 안전하게 공유할 수 있도록 설계된 인증 및 인가 프로토콜이다. 쉽게 설명하면 어떠한 웹사이트에서 구글계정으로 로그인을 할 때 로그인 후 동의화면이 표시되고 허용을 누르게 되는데요. 이 과정이 OAuth2.0을 통해서 나의 신원을 증명해주고 있는 것이다.

 

최근 웹 서비스를 이용하면서 '구글로 로그인', '카카오로 로그인' 버튼을 본 적이 있으실 겁니다. 이러한 간편 로그인 기능이 바로 OAuth 2.0 기술을 활용한 것인데요. 많은 개발자들이 OAuth를 사용하고 있지만, 정작 내부 동작 원리나 다양한 플로우 유형에 대해서는 명확히 알지 못하는 경우가 많습니다.

이 글에서는 OAuth 2.0의 핵심 플로우들을 상세히 살펴보고, 각각의 특징과 적용 시나리오, 그리고 최신 보안 강화 방법까지 포괄적으로 다뤄보겠습니다. 실무에서 바로 활용할 수 있는 실용적인 정보를 중심으로 정리했으니, 끝까지 읽어보시기 바랍니다.

 

OAuth 주요개념

OAuth 2.0은 다음 4가지 주체로 구성됩니다.

Resource Owner (리소스 소유자)

  • 보호되는 리소스에 대한 접근 권한을 부여할 수 있는 주체입니다.
  • 일반적으로 최종 사용자를 의미하며, 구글 계정이나 카카오 계정을 가진 개인 사용자가 해당됩니다.

Client (클라이언트)

  • Resource Owner를 대신하여 보호된 리소스에 접근을 요청하는 애플리케이션입니다.
  • 우리가 개발하는 웹사이트나 모바일 앱이 클라이언트에 해당됩니다.

Authorization Server (인증 서버)

  • Resource Owner를 인증하고 클라이언트에게 액세스 토큰을 발급하는 서버입니다.
  • 구글, 카카오, 네이버 등의 인증 서버가 이에 해당됩니다.

Resource Server (리소스 서버)

  • 보호되는 리소스를 호스팅하고, 액세스 토큰을 통해 접근을 제어하는 서버입니다.
  • 사용자의 프로필 정보, 친구 목록 등의 데이터를 제공하는 API 서버입니다.

 

OAuth 2.0의 핵심 개념

액세스 토큰(Access Token) OAuth 2.0의 핵심은 액세스 토큰입니다. 이 토큰은 임의의 문자열 값으로, 해당 토큰을 발급한 서비스만이 그 정체를 알 수 있습니다. 사용자의 아이디와 비밀번호를 직접 주고받는 대신, 이 토큰을 통해 안전하게 인증을 처리합니다.

Scope (스코프) 클라이언트가 요청할 수 있는 리소스 접근 범위를 제한하는 개념입니다. 예를 들어, 구글 로그인 시 '연락처 읽기', '이메일 주소 확인' 등의 권한을 선택적으로 요청할 수 있습니다.

 

 

주요 플로우 유형 개요

OAuth 2.0은 다양한 사용 환경에 맞춰 여러 가지 인증 플로우를 제공합니다. 각 플로우는 클라이언트의 유형과 보안 요구사항에 따라 선택적으로 사용됩니다.

1. Authorization Code Grant

가장 안전하고 널리 사용되는 플로우입니다. 웹 애플리케이션과 모바일 앱에서 주로 사용됩니다.

2. Implicit Grant

브라우저 기반 애플리케이션을 위해 설계된 플로우입니다. 하지만 보안상의 이유로 현재는 권장되지 않습니다.

3. Resource Owner Password Credentials

사용자의 아이디와 비밀번호를 직접 사용하는 플로우입니다. 높은 신뢰도가 필요한 first-party 애플리케이션에서만 사용됩니다.

4. Client Credentials

사용자 개입 없이 애플리케이션 자체의 권한으로 리소스에 접근하는 플로우입니다.

 

Authorization Code Grant 플로우

Authorization Code Grant는 OAuth 2.0에서 가장 안전하고 권장되는 플로우입니다. 웹 애플리케이션과 모바일 앱에서 주로 사용되며, 2단계 인증 과정을 통해 높은 보안성을 제공합니다.

동작 과정

1단계: 인증 요청 클라이언트가 사용자를 Authorization Server로 리디렉션시킵니다.

 
 
https://authorization-server.com/auth?
  response_type=code&
  client_id=29352735982374239857&
  redirect_uri=https://example-app.com/callback&
  scope=read+write&
  state=xyz123

주요 매개변수는 다음과 같습니다.

  • response_type=code: Authorization Code를 요청함을 명시
  • client_id: 애플리케이션 등록 시 발급받은 고유 식별자
  • redirect_uri: 인증 완료 후 리디렉션될 URI
  • scope: 요청하는 권한 범위
  • state: CSRF 공격 방지를 위한 임의 값

2단계: 사용자 인증 및 동의 사용자가 Authorization Server에서 로그인하고 권한 부여에 동의합니다.

3단계: Authorization Code 발급 인증이 성공하면 Authorization Server가 사용자를 클라이언트로 리디렉션하면서 Authorization Code를 전달합니다.

 
 
https://example-app.com/callback?
  code=SplxlOBeZQQYbYS6WxSbIA&
  state=xyz123

4단계: Access Token 교환 클라이언트가 Authorization Code를 Access Token으로 교환합니다.

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

grant_type=authorization_code&
code=SplxlOBeZQQYbYS6WxSbIA&
redirect_uri=https://example-app.com/callback&
client_id=29352735982374239857&
client_secret=client_secret_value

 

Authorization Code Grant의 장점

높은 보안성 Access Token이 브라우저에 직접 노출되지 않고, 서버 간 통신을 통해 안전하게 교환됩니다.

Client Secret 보호 Client Secret이 프론트엔드에 노출되지 않고 백엔드에서만 사용됩니다.

Refresh Token 지원 장기간 인증 상태를 유지할 수 있는 Refresh Token을 함께 발급받을 수 있습니다.

 

Authorization Code Grant 플로우

Authorization Code Grant는 OAuth 2.0에서 가장 안전하고 권장되는 플로우입니다. 웹 애플리케이션과 모바일 앱에서 주로 사용되며, 2단계 인증 과정을 통해 높은 보안성을 제공합니다.

동작 과정

1단계: 인증 요청 클라이언트가 사용자를 Authorization Server로 리디렉션시킵니다.

 
 
https://authorization-server.com/auth?
  response_type=code&
  client_id=29352735982374239857&
  redirect_uri=https://example-app.com/callback&
  scope=read+write&
  state=xyz123

주요 매개변수는 다음과 같습니다.

  • response_type=code: Authorization Code를 요청함을 명시
  • client_id: 애플리케이션 등록 시 발급받은 고유 식별자
  • redirect_uri: 인증 완료 후 리디렉션될 URI
  • scope: 요청하는 권한 범위
  • state: CSRF 공격 방지를 위한 임의 값

2단계: 사용자 인증 및 동의 사용자가 Authorization Server에서 로그인하고 권한 부여에 동의합니다.

3단계: Authorization Code 발급 인증이 성공하면 Authorization Server가 사용자를 클라이언트로 리디렉션하면서 Authorization Code를 전달합니다.

 
 
https://example-app.com/callback?
  code=SplxlOBeZQQYbYS6WxSbIA&
  state=xyz123

4단계: Access Token 교환 클라이언트가 Authorization Code를 Access Token으로 교환합니다.

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

grant_type=authorization_code&
code=SplxlOBeZQQYbYS6WxSbIA&
redirect_uri=https://example-app.com/callback&
client_id=29352735982374239857&
client_secret=client_secret_value

Authorization Code Grant의 장점

높은 보안성 Access Token이 브라우저에 직접 노출되지 않고, 서버 간 통신을 통해 안전하게 교환됩니다.

Client Secret 보호 Client Secret이 프론트엔드에 노출되지 않고 백엔드에서만 사용됩니다.

Refresh Token 지원 장기간 인증 상태를 유지할 수 있는 Refresh Token을 함께 발급받을 수 있습니다.

 

Implicit Grant 플로우

Implicit Grant는 Authorization Code Grant의 간소화된 버전으로, JavaScript SPA(Single Page Application)를 위해 설계되었습니다. 하지만 보안상의 문제로 현재는 사용이 권장되지 않습니다.

동작 과정

Implicit Grant는 Authorization Code 교환 과정을 생략하고 Access Token을 직접 반환받습니다.

1단계: 인증 요청

 
 
https://authorization-server.com/auth?
  response_type=token&
  client_id=s6BhdRkqt3&
  redirect_uri=https://client.example.com/cb&
  scope=create+delete&
  state=xyz123

2단계: Access Token 직접 반환

 
 
https://client.example.com/cb#
  access_token=2YotnFZFEjr1zCsicMWpAA&
  state=xyz123&
  token_type=bearer&
  expires_in=3600

 

Implicit Grant의 문제점

Access Token 노출 Access Token이 URL 프래그먼트에 포함되어 브라우저 히스토리, 로그, 리퍼러 헤더 등에 기록될 위험이 있습니다.

Refresh Token 미지원 보안상의 이유로 Refresh Token을 제공하지 않아, 토큰 만료 시 재인증이 필요합니다.

CSRF 공격 취약성 적절한 검증 없이 사용될 경우 CSRF 공격에 취약할 수 있습니다.

대안: Authorization Code + PKCE

현재는 Implicit Grant 대신 Authorization Code Grant에 PKCE를 적용하는 방식이 권장됩니다. 이 방법이 더 안전하면서도 SPA에서 효과적으로 사용할 수 있습니다.

 

OAuth를 사용하게된다면?

애플리케이션을 사용하는 유저의 요청에 의해서 Their 서비스에서는 aeesssToken 을 발급해준다.

이 aeesssToken은 Their 서비스의 모든 기능을 사용할 수 있는 것이 아니라 애플리케이션에서 꼭 필요한 Their 서비스의 일부 기능만 허용해준다.

또한 발급받은 accessToken 을 이용해서 Their 서비스에 접근해 데이터를 조회, 수정 등을 할 수 있다.

즉 OAuth 를 사용하면 회원들의 ID, PW 를 알지않아도 회원을 식별할 수 있는 기능을 구현할 수 있다.

 

 

OAuth 목적

OAuth의 목적은 애플리케이션에 사용자의 비밀번호를 직접 제공하지 않게 해 보안이 강화된다. 또한 사용자입장에서는 하나의 계정을 이용해서 여러 애플리케이션에 간편하게 로그인하고 권한을 부여할 수 있기 때문에 새로운 계정을 생성하지 않아도 간편하게 로그인이 가능하다. 

그리고 권한 제어가 가능한데 애플리케이션에 최소 필요한 권한만 허용하고 언제든지 권한을 철회할 수도 있다. 

결국 OAuth는 보안성을 높이고 사용자 편의성을 높여 애플리케이션이 사용자의 데이터를 안전하게 접근하고 관리할 수 있도록 해준다. 

 

 

 

OAuth 동작흐름

 

 

1.Resource Server에 Client 등록

  • 먼저 Client 가 Resource Server 에 등록되어 있어야 한다.
    • 등록요청시 Client ID, Client Secret, Authorized redirect URIs(ex. https://example.com/callback)로 요청
    • 그러면 Authorize Code 가 redirect URIs 로 전달됨

 

2.Resource Owner의 승인

  • Resource Server의 기능이 A,B,C,D 있을때 Client 는 사용할 기능 A,B 기능만 사용한다면 이에 대해서만 사용 인증을 받아야한다.
  • Resource Server의 기능을 사용하기 위해서 Resource Owner의 동의를 받아야 사용이 가능하다.
  • 이때 기능 A,B 는 scope 이라고 불린다.

 

3.Resource Server의 승인

  • redirect URIs로 authorization code (임시 비밀번호)를 발급하는 과정을 의미한다.
  • Resource Server 가 Resource Owner 의 브라우저에게 임시 비밀번호인 authorization code 를 전달해준다. 또한 이 code는 Client 에게 전달이 된다.
  • 그리고 Client는 Client ID, Client Secret, authorization code를 실어서 직접 Resource Server 에게 승인 요청을 보낸다

 

4.AccessToken 발급

  • Resource Server 는 3번에서 받은 승인 요청을 확인해 정보들이 맞다면 Client에게 AccessToken 을 발급해준다.
  • AccessToken은 A 유저가 A,B 기능을 사용할 수 있게 보장해주는 토큰이다.

 

5.API 호출

  • AccessToken을 가지고 Resource Server의 자원에 접근한다.
  • 이때 API 호출을 하면 자원에 접근이 가능하다. (Resource Server 마다 접근방법이 다를 수 있음)

 

6.RefreshToken

  • AccessToken 을 새롭게 발급받을 수 있는 토큰이다.

 

'Development' 카테고리의 다른 글

iOS Swift PassKey 구현 샘플 코드  (0) 2024.10.21
블록체인 지갑 주소 알고리즘에 대하여  (0) 2024.10.20
OpenID Connect 와 Auth2.0  (0) 2024.10.19
Android12 SplashScreen 대응 방법 (feat. 앱 실행상태)  (0) 2024.07.30
Flutter In iOS 14+, debug mode Flutter apps can only be launched from Flutter tooling 오류를 만난 이유  (1) 2024.06.08

관련글

티스토리툴바