Please enable JavaScript.
Coggle requires JavaScript to display documents.
OAuth 2.0 소셜 인증 - Coggle Diagram
OAuth 2.0 소셜 인증
OAuth란?
사용자가 애플리케이션에 자신의 로그인 자격 증명을 직접적으로 공유하지 않고도, 해당 애플리케이션이 특정 범위(scope) 내에서 자신의 리소스에 접근할 수 있도록 권한을 위임하는 개방형 인증 표준 프로토콜(RFC-6749)
탄생 배경
기존 인증 방식의 한계
초기 인증 방식은 사용자의 비밀번호를 애플리케이션에 직접 제공해야 했고, 이로 인해 비밀번호 유출이나 피싱 공격 등의 보안 위험이 존재.
하나의 서비스에서 유출된 정보는 다른 애플리케이션에도 영향을 미칠 수 있어 위험함.
따라서, 더욱 안전하고 효율적인 인증 및 권한 부여 매커니즘을 제공하고자
OAtuth(Open Authorization) 탄생
서비스 간 데이터 공유 필요성
다양한 플랫폼과 서비스가 연동되면서, 사용자 데이터에 안전하게 접근할 수 있는 새로운 인증 및 권한 위임 방식의 필요성이 대두됨
웹, 모바일, 데스크톱 등 다양한 환경에서 사용하기 위해 여러 인증(grant) 방식이 존재한다
Versions
OAuth 1.0
-
-
한계점
서명 기반의 복잡한 구조
모든 요청에 대해 암호화된 서명을 생성하고 검증 과정으로 사용해, 서버측에서 검증 로직을 구현하고 관리하는 데 어려움
확장성 부족
제한된 인증 방식으로 인해 모바일 애플리케이션과 같은 다양한 환경에서의 사용이 어려웠고, 이로 인해 다른 플랫폼에서의 적용이 쉽지 않음
토큰 재사용 가능성의 위험
액세스 토큰의 유효기간에 대한 명확한 스펙이 없어 재사용이 가능할 수 있는 위험성이 존재했고, 토큰을 무효화하려면 서비스 제공자의 애플리케이션에서 비밀번호를 직접 변경해야 했음
OAuth 2.0
Terms
Key Terms
Resource Owner
보호된 자원에 접근 권한을 가진 최종 사용자(개인)로 리소스 서버에 계정을 소유하며, 자신의 정보에 대한 접근 권한을 Client에 부여한다
Client
사용자에게 권한을 부여 받아, Resource Server에 있는 사용자의 보호된 자원에 접근하려는 애플리케이션으로,
사용자를 대신해 실제로 요청을 처리하고 서버들과 상호작용하는 주체이다
Public Client
- 클라이언트의 비밀 정보를 안전하게 보호할 수 없는 환경에서 운용되는 애플리케이션. 대표적으로 모바일 앱, 웹 기반 애플리케이션, 공용 데스크톱 애플리케이션 등 사용자 장치에서 실행되는 클라이언트가 해당된다.
- Access Token: 인가 서버가 별도의 통신 채널을 사용하지 않고, 프론트엔드에서 URL을 통해 사용자에게 직접 전달하며, Implicit Grant 방식에 해당한다.
- 장점
- 배포와 사용이 간편하고, 개발과 유지보수가 비교적 쉬움
- 클라이언트 자격 증명을 안전하게 저장할 필요가 없으므로, 다양한 플랫폼에서 환경에 구애받지 않고 유연한 사용이 가능
- 취약점
- 인가 서버로 부터 액세스 토큰이 직접 전달되므로, 토큰이 사용자 화면에 그대로 노출이 되어, 외부 사용자에 의한 토큰 탈취 위험 존재
Confidential Client
- 클라이언트의 비밀을 안전하게 저장하고 관리할 수 있는 환경에서 운용되는 애플리케이션. 주로 서버 측에서 실행되는 백엔드 서비스나 데스크톱 애플리케이션이 해당된다.
- Acess Token: 인가 서버에서 인가 코드(Authorization Code)를 받은 뒤, 이를 이용해 액세스 토큰으로 교환하는 과정을 거친다. Authorization Code Grant 방식과 Password Credentials Grant 방식이 포함된다.
- 장점
- 액세스 토큰 발급 과정에서 인가 코드는 철저히 백엔드에서 처리하여, 공개 클라이언트와 달리 사용자에게 토큰 정보가 노출될 위험이 없음
- 인가 코드가 탈취되더라도, 이를 검증하기 위한 보안 토큰이 없으면 액세스 토큰이 발급되지 않기 때문에 보안성이 우수함
Authorization Server
실질적인 인증과 인가를 수행하는 서버로, Client의 접근 자격을 확인하고, 사용자의 동의를 받아 권한 부여를 위한 Access Token을 발급한다
Resource Server
사용자의 보호된 자원(ex.개인정보)을 호스팅하고, 클라이언트가 제공한 Access Token을 검증하여 해당 자원에 대한 접근을 허용하는 자원 서버
Tokens
ID Token
- 사용자 인증 정보를 담고 있는 토큰으로, 클라이언트는 ID Token을 이용해 사용자의 인증 상태를 확인
- OAuth 2.0 서버의 일종인 OpenID Provider가 발행
- OpenID Provider가 최종 사용자를 인증하고 그 결과와 사용자의 정보를 클라이언트에게 제공하는 과정에서 사용자의 신분을 증명하는 역할
Access Token: 무엇을 할 수 있는지 (권한)
ID Token: 누가 인증 되었는지 (사용자 정보)
- 리소스 서버 접근 권한
- Access Token (O) / ID Token (X)
- 사용자 정보 획득 권한
- Acess Token (X) / ID Token (O)
Access Token
클라이언트에서 사용자의 보호된 리소스에 접근하는데 사용되는 자격 증명으로 리소스에 대한 접근 권한을 사용자가 인가하였음을 나타낸다.
일반적으로 짧은 유효기간이 설정되어 있고, 만료되면 refresh token으로 새로 발급 받을 수 있다.
독립형 타입(Self-contained Type)
- 확장성과 효율성 측면에서 많은 이점을 제공하여 가장 널리 사용되는 방식
- 토큰 자체에 필요한 모든 정보를 포함
- 인가 서버와의 추가적인 통신 없이 리소스 서버에서 자체적으로 액세스 토큰 검증 가능
- 대표적인 방식: JWT(JSON Web Token)
- 장점
- 리소스 서버가 독립적으로 토큰의 유효성을 검증하여, 검증 소요 시간이 짧고, 추가적인 리소스의 소모 감소
- 네트워크 부하가 감소되어, 요청 빈도가 높은 시스템에서 이점이 두드러짐
- 인가 서버에 대한 의존도 감소로, 인가 서버 장애 시에도 영향이 최소화됨
- 액세스 토큰이 비저장(stateless) 방식으로 운영되어, 인가 서버기 토큰의 상태를 관리할 필요가 없음 => 장애 복구, 서버 간 세션 공유가 불필요
- 주의점
- 한 번 발급된 토큰의 내용을 변경할 수 없어, 사용자의 권한이나 정보가 변경되면 새로운 토큰을 발급 필요
- 따라서, 권한 변경이나 정보 갱신이 어려움
- 토큰 자체에 중요 정보가 모두 포함되어, 토큰이 탈취될 경우 사용자의 민감 정보도 함께 노출 될 위험 높음
- 토큰 탈취 위험으로 인해 짧은 만료 시간 + 리프레시 토큰 + HTTPS 사용이 필수
식별자 타입(Identifier Type)
- 정보 유출에 민감한 시스템에서 많이 사용되는 방식
- 토큰 자체에 최소한의 정보를 포함
- 리소스 서버가 토큰의 유효성을 검증하기 위해 별도로 인가 서버와 통신하는 과정이 필요
- 대표적인 방식: Opaque Token(불투명 토큰)
- 장점
- 토큰 자체에 민감 정보가 포함되지 않아, 외부에 토큰이 유출되더라도 정보의 직접적인 노출이 없음
- 짧은 문자열로 구성된 경량화된 구조를 가지고 있어, URL 매개변수로 쉽게 전달 가능 => 토큰 발급과 검증 과정에서의 처리 부담 감소
- 주의점
- 리소스 서버가 토큰의 유효성을 검증하기 위해 반드시 인가 서버와 통신하는 절차가 필요하므로, 인가 서버에 대한 의존도가 높음
- 이로 인해, 인가 서버에서 네트워크 지연으로 인한 응답 시간 증가, 혹은 사용성이나 성능 문제 발생 시, 전체 시스템이 영향을 받음
- 각 토큰 요청마다 인가 서버와의 통신이 필수적이므로, 트래픽이 늘어나게 되어 서버의 부하 증가
Refresh Token
- Access Token이 만료되었을 때, 클라이언트가 새로운 액세스 토큰을 발급 받기 위해 사용하는 장기 유효 자격 증명
- 2.0에서 액세스 토큰의 유효기간 설정으로, 토큰의 재발급이 필요한 경우 발생
- 인가 서버에서 액세스 토큰과 함께 발행되며, 클라이언트가 관리한다
Secondary Terms
Authorized Redirect URIs
- 인가 서버에서 클라이언트 서버로 Authorization Code를 전달하는 URL 통로로, 인가 서버 -> 사용자 -> 클라이언트 순으로 전달된다.
- 클라이언트와 리소스 서버의 유효성 검사에도 사용되는데,
redirect uri가 대상 클라이언트의 URIs에 존재하지 않으면, 리소스 서버에서 해당 클라이언트가 아니라고 판단하여 인증에 실패한다.
Client ID / Client Secret
- Client ID: 리소스 서버를 사용하고자 하는 서비스의 식별자 ID
- Client Secret: Client ID에 대한 PW로, 외부 노출이 되면 안됨
-
-
-
개선된 점
서버 구조의 분리
1.0에서 단일 서버로 통합 처리하던 인증, 권한 부여, 자원 제공 과정을 인증 및 권한 부여 서버(인가 서버)와 리소스 서버로 분리하여 시스템의 유연성과 확장성 증가
-
HTTPS 암호화(서명 과정 제거)
HTTPS 프로토콜을 통한 암호화를 필수적으로 적용하도록 하여 1.0에서 요구되던 복잡한 서명 과정을 제거, 이로 인해 기능 구현이 간소화되고, 다양한 인증 수단을 지원하게 되어 범용성 향상
인증 방식(Grant Types)
Authorization Code Grant
(인가 코드 방식)
주로 서버 사이드 애플리케이션에서 사용되며, 보안성이 높은 대표적 기밀 클라이언트 유형.
클라이언트는 인가 서버로부터 인가 코드(Authorization Code)를 받아, 이를 Access Token으로 교환한다.
이로 인해 민감 정보가 사용자 에이전트(브라우저)나 프론트엔드에 노출되지 않아 토큰 탈취의 위험성이 적다.
보안이 중요한 애플리케이션에 적용되며, 간편 로그인 기능에서 사용되는 방식이다.
리프레시 토큰을 사용할 수 있다.
과정
사용자가 앱에 접속
클라이언트가 인가 서버로 일회용 인가 코드 요청
(이 때, Clietn ID, Redirect URI, scope 정보 포함)
로그인 페이지로 이동 후, 사용자가 권한 위임 승인
인가 서버는 인증 요청의 유효성 검증 후, 클라이언트로 인가 코드 발행
- 1 more item...
-
[PKCE]
- 클라이언트에서 랜덤한 문자열(Code Verifier) 생성
- Code Verifier를 SHA-256 해시하여 Code Challenge 생성
PKCE-enhaced Authorization Code Grant
공개 클라이언트(모바일 앱, SPA 등)에서 인가 코드 탈취 공격을 방지하기 위해 추가적인 보안 강화 매커니즘으로 PKCE(Proof Key for Code Exchange)를 적용한 방식.
일반적인 Authorized Code Grant 방식에서는 인가 코드만 있어도 Access Token을 요청할 수 있지만, PKCE 방식에서는 Code Verifier가 있어야만 토큰을 요청 가능.
서버 기반 웹 애플리케이션은 PKCE 없이도 안전.
Implicit Grant
(암묵적 승인 방식)
주로 자바스크립트 기반의 클라이언트(브라우저)에서 사용되며, 빠른 토큰 전달이 가능하다.
하지만, 액세스 토큰이 URL에 노출되는 단점으로 인해 보안성이 낮아, 현재는 권장되지 않는다.
과정
사용자가 앱에 접속
클라이언트에서 인가 서버로 인증 요청
인가 서버에서 요청의 유효성 검증 후, 액세스 토큰 발급
-
Resource Owner Password Credentials Grant
(자원 소유자 자격증명 승인 방식)
사용자가 자신의 ID와 PW를 클라이언트에 직접 제공하는 방식.
구현은 간단하지만, 보안 위험이 크므로 신뢰할 수 있는 애플리케이션(ex.내부 애플리케이션)에서만 사용해야 한다.
-
Client Credentials Grant
(클라이언트 자격증명 승인 방식)
사용자가 인증을 수행하지 않고, 클라이언트가 자체 자격 증명을 이용해 액세스 토큰을 요청하는 방식.
사용자의 개입이 없어 서버 간 통신에 적합하며, 내부 서비스를 연동하는 데 유용하다.
-
1.0 vs. 2.0
- 다양한 인증 방식: 1가지 => 4가지
- 간편한 구현: 기능의 단순화, 기능과 규모의 확장성 지원
- 강화된 보안 제공:
- HTTPS 암호화 필수 적용
- API 서버에서 Authorization Server / Resource Server 분리
취약점
JWT 정보 추출 위험
JWT는 Base64Url로 인코딩 되어 있으므로, 토큰이 노출될 경우 간단한 디코딩 과정만으로도 중요한 정보가 유출될 수 있는 위험 존재.
따라서, 토큰의 보안 관리에 각별한 주의가 필요.
Base64Url: 대칭키나 비대칭키를 이용한 암호화 방식이 아닌, ASCII 문자를 사용하여 이진 데이터를 문자열로 표현한 인코딩 방식
Access Token 탈취 위험
Implicit Grant 방식은 액세스 토큰이 URL에 노출되므로, 토큰 탈취의 위험이 존재. 이러한 이유로 사용이 권장되지 않음.
특히 토큰 탈취 위험 때문에 JWT를 사용할 때는
짧은 만료 시간 + 리프레시 토큰 + HTTPS 사용이 필수
보안 고려 사항
토큰 라이프사이클 관리
- Access Token: 유효 기간, 재발급 정책, 토큰 블랙리스트 등을 설정하여 탈취된 토큰의 재사용 위험 최소화
- Refresh Token: 리프레시 토큰 역시 탈취되면 장기간 공격에 이용될 수 있으므로, 재발급 시점과 폐기 정책의 엄격한 관리가 필요
- 폐기 정책: 토큰을 서버내에서 무효화(blacklisting)하는 전략, 혹은 짧은 만료 시간과 정기적인 재발급 정책을 통해 관리하는 방법이 있으며, 각 시스템의 요구 사항에 따라 달라질 수 있음
운영 및 유지보수 측면의 관리
- 로그 및 모니터링: 토큰 발급, 재발급, 폐기 등의 모든 이벤트를 기록하여, 보안 사고 발생 시 빠른 대응이 가능하도록 함
- 자동화:토큰 만료 및 재발급을 자동화하는 시스템을 도입할 경우, 운영 부담을 줄이고 보안성을 높일 수 있음
Open Redirect 정보 탈취 위험
클라이언트가 인가 서버에 토큰을 요청할 때 포함되는 매개변수 중 redirect_uri는
인증 완료 후 인가 서버가 결과를 전달할 주소를 지정하는 역할을 한다.
이는 인증 절차가 끝난 후 사용자를 리다이렉트할 페이지를 나타내며,
검증이 철저하게 이뤄지지 않을 경우, 공격자가 이를 조작하여 사용자를 악의적인 피싱 사이트로 유도하거나
인가 서버가 발급한 액세스 토큰을 탈취하는 등의 공격이 발생할 수 있다.
인가 서버에서 redirect_uri를 설정하는 방식
- 클라이언트가 인증 결과를 수신할 URI를 명시적으로 지정 (권장)
- 특정 경로에 wildcard를 사용해 설정
- 보안 측면에서 다른 취약점과 결합되어 악용될 가능성 존재
소셜 로그인 서비스
Google
비용
기본적으로 무료로 제공되지만,
API 호출량에 따른 비용 발생 가능
장점
- 광범위한 사용자층: 구글 계정으로 보유한 전 세계적 사용자에게 접근 가능
- 보안성: 구글의 강력한 보안 시스템을 기반으로 안전한 인증 제공
단점
- 개발 복잡성: 구글의 인증 시스템을 구현하고 관리하는데에는 일정한 학습 곡선과 개발 시간이 필요
Apple
비용
애플 로그인 자체는 무료로 제공되지만, 애플 개발자 프로그램 등록 비용 발생 가능
장점
- 개인 정보 보호: 사용자의 이메일 주소를 공개하지 않고도 인증할 수있는 기능 제공
- Apple 생태계와 통합: iOS 및 macOS 플랫폼과의 원활한 통합으로 사용자 경험 향상
- 보안성: 애플의 보안 프로토콜을 기반으로 안전한 인증 제공
단점
- 제한된 사용자층: 애플 기기를 사용하지 않는 사용자에게는 접근 불가
- 개발 요구 사항: 애플 로그인을 구현하기 위해서는 특정 개발 요구 사항과 절차를 따라야 함
Kakao
장점
- 편의성: 카카오톡과 카카오 계정을 이용한 손쉬운 로그인으로 인해 사용자 경험 향상
- 개발 효율성: OAuth 2.0 기반의 인증 시스템을 제공해 별도의 인증 시스템을 구축 불필요
- 관리 기능: 카카오디벨로퍼스의 관리 콘솔을 통해 사용자 관리 및 데이터 분석 기능 제공
단점
- 의존성: 카카오의 인증 시스템에 의존하게 되어, 카카오 서비스에 장애 발생 시 영향
- 사용자 정보 제한: 사용자 정보 수집 시, 카카오에서 제공하는 범위 내에서만 가능하며 일부 정보는 추가 동의가 필요
비용
기본적인 기능은 무료로 제공되지만, 대량의 트래픽이나 추가 기능을 사용할 경우 비용이 발생할 수 있음