OAuth란? "Google로 로그인"과 위임된 접근 권한 설명

OAuth는 사용자가 비밀번호를 넘기지 않고도 한 앱에 다른 서비스의 자기 계정에 대한 제한된 접근 권한을 줄 수 있게 해 주는 개방형 표준입니다. "Google 캘린더 연결"을 클릭했을 때 "이 앱이 내 일정을 보도록 허용하시겠습니까?"라고 묻는 화면이 나타난다면, 그것이 OAuth입니다. 앱은 여러분이 승인한 것에만 해당하는 토큰을 받으며, 이 토큰은 언제든지 취소할 수 있습니다. 같은 구조에 OpenID Connect라는 추가 계층을 더하면 "Google로 로그인"과 비슷한 버튼이 만들어집니다.

AI로 만들 때 OAuth가 중요한 이유

앱을 만들 때 OAuth는 두 가지 흔한 상황에서 등장합니다.

1. 소셜 로그인. 사용자가 새 비밀번호를 만드는 대신 "Google로 로그인"(또는 Apple, Microsoft, GitHub)을 사용하기를 원합니다. 앱에 로그인을 추가하는 방법을 참고하세요.
2. 다른 서비스의 사용자 계정에 연결. 앱이 사용자의 캘린더를 읽거나, 사용자의 소셜 계정에 게시하거나, 클라우드 드라이브에서 파일을 가져오거나, 회계 데이터를 동기화해야 합니다.

두 경우 모두 AI 빌더가 코드를 작성할 수 있지만, 일부 단계는 여러분만 할 수 있습니다. 제공업체에 개발자 앱을 만들기, 클라이언트 ID와 클라이언트 시크릿 받기, 콜백 URL 등록, 일부 권한의 경우 제공업체의 심사 통과가 여기에 해당합니다. OAuth가 어떻게 작동하는지 알면 이런 단계와 그로 인해 생기는 오류가 훨씬 덜 낯설게 느껴집니다. 로그인 전반에 대한 큰 그림은 인증이란 무엇인가요를 참고하세요.

일상적인 비유

호텔 키카드를 떠올려 보세요. 체크인할 때 프런트 데스크가 여러분이 누구인지 확인한 뒤, 여러분의 객실과 헬스장은 열리지만 다른 객실이나 직원 구역은 열리지 않는 카드를 줍니다. 체크아웃하면 카드는 작동을 멈춥니다. 카드에는 여러분의 여권 정보가 들어 있지 않습니다. 카드를 잃어버리면 프런트에서 그 카드를 취소하고 새 카드를 발급합니다.

• 프런트 데스크는 인가 서버(Google의 로그인 페이지)입니다.
• 신분 확인은 여러분이 Google에 로그인하는 것입니다.
• 키카드는 액세스 토큰입니다.
• **"객실과 헬스장만"**은 여러분이 승인한 스코프입니다.
• 체크아웃은 토큰이 만료되거나 여러분이 접근 권한을 취소하는 것입니다.

사용하는 앱은 여러분의 Google 비밀번호를 보지 못하고, 키카드만 봅니다.

OAuth 작동 방식 단계별 설명

웹 앱에서 가장 흔한 흐름은 *인가 코드 흐름(authorization code flow)*입니다. 사용자가 일정 관리 앱에 Google 캘린더를 연결할 때 일어나는 일은 다음과 같습니다.

1. 클릭. 사용자가 "Google 캘린더 연결"을 클릭합니다.
2. 제공업체로 리디렉션. 앱은 브라우저를 Google로 보내며, 여기에는 클라이언트 ID, 요청하는 스코프(캘린더 일정 읽기), 그리고 Google이 사용자를 돌려보내야 할 리디렉션 URI가 포함됩니다.
3. 로그인과 동의. 사용자는 (아직 로그인하지 않았다면) Google에 로그인하고, 앱이 요청하는 내용을 나열한 동의 화면을 봅니다. 허용을 클릭합니다.
4. 코드와 함께 돌아옴. Google은 짧은 수명의 일회용 인가 코드와 함께 브라우저를 앱의 리디렉션 URI로 보냅니다.
5. 서버에서 교환. 앱의 서버가 그 코드와 클라이언트 시크릿을 Google에 직접 보내고, 액세스 토큰(그리고 흔히 리프레시 토큰)을 받습니다.
6. API 사용. 서버는 액세스 토큰으로 Google 캘린더 API를 호출해 사용자의 일정을 가져옵니다.

4단계의 콜백은 다음과 비슷하게 생겼습니다.

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

그리고 5단계의 토큰 응답은 다음과 같은 JSON입니다.

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

중요한 설계 포인트는 토큰 교환이 서버 간에 이루어진다는 점입니다. 그래서 클라이언트 시크릿과 토큰이 브라우저를 거칠 필요가 없습니다.

OAuth vs OpenID Connect vs 직접 만든 로그인

많은 앱이 이들을 함께 사용합니다. 이메일과 비밀번호 로그인, OIDC를 통한 "Google로 로그인", 그리고 다른 서비스에 대한 별도의 OAuth 연결을 조합하는 식입니다.

핵심 용어

흔한 오해

• "OAuth는 로그인 시스템이다." 순수한 OAuth는 접근 권한을 부여할 뿐이며, 신원은 OpenID Connect가 처리합니다. 액세스 토큰만으로 누군가가 누구인지 증명하려 하면 실제 보안 버그가 생겼습니다.
• "앱이 내 비밀번호를 받는다." 절대 그렇지 않습니다. 그것이 핵심입니다.
• "스코프를 더 요청해도 해가 없다." 사용자는 광범위한 요청을 더 경계하며, Google 같은 제공업체는 민감하거나 제한된 스코프에 대해 앱 심사를 요구할 수 있습니다. 필요한 것만 요청하세요.
• "클라이언트 시크릿은 프런트엔드에 둬도 된다." 브라우저 코드에 있는 것은 모두 공개됩니다. 서버 측 비밀 정보에 보관하세요.
• "테스트에서 작동하니 운영에서도 작동한다." 제공업체는 검증되지 않은 앱을 제한하는 경우가 많습니다(예: 등록된 테스트 사용자만 허용). 그리고 실서비스 도메인의 리디렉션 URI는 별도로 등록해야 합니다.
• "토큰은 영원히 유효하다." 액세스 토큰은 빠르게 만료되며, 사용자는 접근 권한을 취소할 수 있습니다. 앱은 두 경우 모두 자연스럽게 처리해야 합니다.

AI 빌더에 요청하면 좋은 것

• "잘 관리되는 인증 라이브러리로 OpenID Connect를 사용해 'Google로 로그인'을 추가해 줘. OAuth 흐름을 직접 구현하지는 마."
• "PKCE를 사용하는 인가 코드 흐름을 쓰고 state 매개변수를 확인해 줘."
• "클라이언트 ID와 클라이언트 시크릿은 서버의 환경 변수에서 읽어 줘."
• "필요한 스코프만 요청해 줘. 캘린더 읽기 전용 접근이면 충분해."
• "미리보기, 게시된 URL, 커스텀 도메인마다 제공업체 콘솔에 등록해야 할 리디렉션 URL을 모두 알려 줘."
• "리프레시 토큰은 데이터베이스에 암호화해 저장하고, 만료되거나 취소된 토큰은 사용자에게 다시 연결하도록 요청하는 방식으로 처리해 줘."
• "사용자가 설정 페이지에서 연동을 해제할 수 있게 해 줘."

OAuth와 Mythex

Mythex에는 여러분이 만든 앱을 위한 내장 최종 사용자 로그인이 없습니다. Mythex 문서는 직접 가져오는(bring-your-own) 방식을 설명합니다. 인증 라이브러리나 호스팅 제공업체를 직접 고르고, 그 키를 프로젝트 비밀 정보로 저장하면 에이전트가 코드를 작성합니다. 인증 추가 레시피에 이를 위한 시작 프롬프트가 있습니다. Mythex 자체에서도 OAuth를 만나게 됩니다. Google로 가입할 수 있고, 저장소 동기화를 위해 GitHub를 연결하면 GitHub OAuth를 사용하며, MCP로 Mythex에 연결하는 AI 클라이언트는 OAuth 동의 페이지를 거칩니다. 더 알아보려면 인증이란 무엇인가요와 2단계 인증이란 무엇인가요를 참고하세요.

자주 묻는 질문