<h1><center> OAuth </center></h1> ###### tags: `OAuth` - ###### date - `2025-03-201 7:21:33.284Z` > [color=#724cd1][name=데릭] > [Charming-kyu blog](https://charming-kyu.tistory.com/36) > [Chat GPT] ## OAuth > 사용자의 아이디와 비밀번호를 직접 제공하지 않고, 안전하게 권한을 위임하는 인증 방식을 말한다. **주요 개념** | 개념 | 설명 | | -------- | -------- | | Client | 인증을 요청하는 주체(iOS 앱) | | Resource Owner(사용자) | 리소스를 제공하는 사용자 (iOS 앱 사용자) | | Authorization Server(인증 서버) | 사용자의 인증을 담당하는 서버(Google, Kakao, Apple, Facebook 등) | | Resource Server(리소스 서버) | 보호된 리소스를 제공하는 서버(API 서버) | | Access Token(액세스 토큰) | 인증 후 API 요청 시 필요한 키(짧은 유효기간) | | Refresh Token(리프레시 토큰) | 액세스 토큰 만료 시 재발급하는 키(긴 유효기간) | **OAuth 2.0 인증 과정** 1. 사용자가 iOS 앱에서 로그인 버튼을 누름 - iOS 앱(Client)이 인증 서버에 로그인 요청을 보냄 - 사용자는 인증 서버에서 로그인 후 권한을 승인함 2. Authorization Code 발급 - 인증 서버가 iOS 앱(Client)에게 Authorization Code를 발급함 - 이 코드는 액세스 토큰을 요청할 때 사용됨 3. Access Token 요청 - iOS 앱(Client)이 Authorization Code를 인증 서버에 보내고 Access Token을 요청함 - 인증 서버가 Access Token을 발급해줌 4. API 요청 및 데이터 반환 - iOS 앱은 Access Token을 사용해 리소스 서버에 API 요청을 보냄 - 리소스 서버가 데이터를 반환함 **OAuth 2.0의 권한 부여 방식** 1. 권한 부여 코드 승인 방식(Authorization Code Grant): ![image](https://hackmd.io/_uploads/rJKhhGc3kl.png) 가장 널리 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용됩니다. **동작방식** 1. 클라이언트(앱/웹)는 사용자를 OAuth 제공자(구글, 페이스북 등)의 로그인 페이지로 리다이렉트 시킴 2. 사용자가 로그인 & 권한을 승인 하면 Authorization Code를 클라이언트에게 전달 3. 클라이언트는 Authorization Code를 가지고 OAuth 서버(Authorization Server)에 Access Token 요청 4. OAuth 서버는 Authorization Code를 검증한 후, Access Token과 Refresh Token을 발급 5. 클라이언트는 Access Token을 이용해 API 요청 및 사용자 데이터 접근 **주요 특징** - 보안성이 뛰어남 → Access Token을 직접 주는 게 아니라 Authorization Code를 한 번 더 거치기 때문. - Refresh Token 사용 가능 → Access Token이 만료되면 Refresh Token을 사용해 새로운 Access Token을 발급받을 수 있음. - 보통 간편 로그인 (OAuth 로그인)에 사용됨 → 구글, 페이스북, 애플 로그인 등. - 타사 클라이언트(예: 외부 웹사이트, 앱)에서도 안전하게 사용할 수 있음. 2. Implicit Grant (암묵적 승인 방식) ![image](https://hackmd.io/_uploads/rkeZWm5hJx.png) - 보안성이 낮아 OAuth 2.1에서는 폐기 예정(SPA, JS 기반 앱에서 사용되던 방식) **동작방식** 1. 클라이언트(앱/웹)가 사용자를 OAuth 제공자 로그인 페이지로 리다이렉트 2. 사용자가 로그인 & 권한 승인하면 Access Token을 직접 전달 3. 클라이언트는 Access Token을 이용해 API 요청 및 사용자 데이터 접근 **✔️ 결론** - Access Token이 URL을 통해 전달되기 때문에 보안에 취약해서 사용을 권장하지 않음. - 대신 PKCE (Proof Key for Code Exchange) 방식이 도입되었고, OAuth 2.1에서는 폐기될 예정! 3. Resource Owner Password Credentials Grant (비밀번호 인증 방식) ![image](https://hackmd.io/_uploads/SkI3f7q3ye.png) - 사용자의 ID/PW를 직접 입력해야 해서 보안에 취약 **동작방식** - 클라이언트(앱/웹)가 사용자의 ID/PW를 입력받아 OAuth 서버에 직접 전송. - OAuth 서버가 ID/PW를 검증하고, Access Token과 Refresh Token을 발급. - 클라이언트는 Access Token을 이용해 API 요청 및 사용자 데이터 접근. 4. Client Credentials Grant (클라이언트 자격 증명 방식) ![image](https://hackmd.io/_uploads/BkwpMXchkx.png) - 사용자 없이, 클라이언트(서버)가 자체적으로 API를 호출할 때 사용 **동작 방식** - 클라이언트(서버)가 OAuth 서버에 클라이언트 ID & Secret을 보내 Access Token 요청. - OAuth 서버가 클라이언트 ID & Secret을 검증하고, Access Token을 발급. - 클라이언트는 Access Token을 이용해 API 요청 및 데이터 접근. --- ## NOTE **SPA & JS 기반 앱** **1️⃣ SPA (Single Page Application, 단일 페이지 애플리케이션)** - 한 개의 HTML 페이지에서 모든 기능을 처리하는 웹 애플리케이션 - 페이지 전환 없이 화면을 동적으로 업데이트하는 방식 - 예제: Gmail, Trello, Facebook, Twitter 웹앱 **어떻게 동작해?** - 처음에 한 개의 HTML, CSS, JavaScript 파일을 로드 - 이후에는 필요한 데이터만 가져와서 화면을 변경 (새로고침 없음) - 주로 React, Vue.js, Angular 같은 프레임워크로 개발 **장점** - 빠른 화면 전환 (새로고침 없이 동작) - 서버 요청이 줄어들어 성능 최적화 가능 **단점** - 초기 로딩 속도가 느릴 수 있음 - 보안 (XSS 공격)에 취약할 수 있음 **JS 기반 앱 (JavaScript 기반 애플리케이션)** - JavaScript로 작성된 웹 애플리케이션 - 클라이언트에서 실행되며, 브라우저가 직접 로직을 처리 - 예제: React, Vue.js, Angular로 개발된 모든 웹앱 **📌 SPA와 차이점** - SPA는 JS 기반 웹앱의 한 종류일 뿐이고, - JS 기반 웹앱에는 SPA뿐만 아니라 전통적인 MPA (Multi-Page Application)도 포함될 수 있음. **✔️ SPA와 JS 기반 앱을 쉽게 구분하자면?** - SPA: 하나의 HTML 페이지에서 동작하는 JS 웹앱 (React, Vue.js 등) - JS 기반 앱: 모든 JavaScript로 동작하는 웹앱 (SPA + 전통적인 JS 앱 포함) **📌 OAuth 2.0에서 왜 중요해?** SPA와 JS 기반 앱은 브라우저에서 직접 실행되기 때문에 보안이 중요함 --- **PKCE (Proof Key for Code Exchange)란?** - OAuth 2.0의 Authorization Code Grant 방식에서 보안성을 강화하기 위한 추가 인증 기법 - 특히 SPA (Single Page Application)나 모바일 앱에서 보안 강화를 위해 사용됨. 1. PKCE가 왜 필요할까? (Authorization Code Interception 공격 방지) - 기본적인 Authorization Code Grant 방식은 보안성이 높은 방식이지만 클라이언트 시크릿을 사용함 **-> 모바일 앱이나, SPA 같은 공개 클라이언트는 Client Secret을 안전하게 보관할 수 없음** 그래서~ 공격자가 Authorization Code를 가로채서 Access Token을 발급받는 문제(Authorization Code Interception Attack)가 발생할 수 있음 - PKCE는 이 문제를 해결하기 위한 보안 강화 방식 - Client Secret 없이도 Authorization Code Grant를 안전하게 사용할 수 있도록 보완하는 방법 **PKCE의 동작 방식** - PKCE를 사용하면 클라이언트가 Access Token을 요청할 때 추가적인 보안 검증을 수행함 - 즉, 클라이언트가 미리 생성한 코드(Code Verifier & Code Challenge)를 통해 인증을 강화하는 방식 **PKCE 동작 과정** 1. 클라이언트(앱/웹)가 Code Verifier를 생성 - 랜덤한 문자열 (43~128자의 고유한 값) - 예: wxyz1234567890abcdef 2. Code Verifier를 변환하여 Code Challenge를 생성 - 일반적으로 SHA-256 해시를 적용하여 Code Challenge 생성 - 예: S256(wxyz1234567890abcdef) = hashed_code_challenge_value 3. 클라이언트가 Code Challenge를 포함하여 Authorization Code 요청 - 사용자가 로그인 후 OAuth 서버로부터 Authorization Code를 받음 - 이때, Code Challenge도 함께 전송 4. Authorization Code를 받은 후, Access Token 요청 시 Code Verifier 포함 - 클라이언트가 Access Token 요청 시 미리 생성했던 Code Verifier를 함께 전송 - OAuth 서버가 Code Verifier를 검증하여 Code Challenge와 일치하는지 확인 5. OAuth 서버가 검증 후, Access Token 발급 --- **OAuth 2.0에서 Access Token과 Refresh Token의 차이?** - Access Token은 API 요청에 사용 - Refresh Token은 Access Token을 갱신하는 데 사용 **OAuth 2.0에서 Authorization Code Flow를 사용하는 이유?** - 직접 Access Token을 노출하지 않고 보안을 강화하기 위해 **📌 Access Token은 왜 Keychain에 저장해야 할까?** - Keychain은 iOS에서 제공하는 가장 안전한 저장소(암호화됨) - 앱 삭제 후에도 유지 가능 - 다른 앱이 접근 불가 - UserDefaults, 파일, CoreData는 안전하지 않음 **Keychain이 아닌 곳에 저장하면 어떤 문제가 생길까?** 1. UserDefaults에 저장할 경우 - 해킹 툴(탈옥된 기기 등)로 쉽게 추출 가능 - 앱이 재설치되면 데이터가 사라짐 UserDefaults는 암호화되지 않으며, 앱 내부 파일에 평문(Plain Text)으로 저장됨 - 기본적으로 앱 샌드박스 내부에서만 접근 가능 → 다른 앱은 접근 불가. - 하지만 탈옥된 기기에서는 다른 앱이나 해킹 툴이쉽게 접근 가능! 2. 파일에 저장할 경우 - 앱 샌드박스를 우회하면 파일을 직접 읽을 수 있음 - 악성 앱이 접근할 가능성이 있음 3. CoreData는 안전할까? - CoreData도 기본적으로 암호화되지 않음 - SQLite 기반으로 데이터를 저장하는데, 디스크에 평문 저장됨. - 앱 샌드박스 내에 있지만, 탈옥된 기기에서는 SQL 파일을 직접 열어볼 수 있음. - 만약 보안이 필요하다면 NSPersistentStoreCoordinator를 사용해 암호화 적용 필요.