한 줄 정의

OAuth는 외부 앱이나 Agent에게 비밀번호를 넘기지 않고 제한된 접근 권한을 주게 만드는 권한 위임 프로토콜이야. 사용자가 서비스에 직접 로그인하고 동의하면, 앱은 비밀번호 대신 access token을 받아 정해진 scope 안에서 API를 호출해.

그래서 OAuth는 “로그인 버튼” 자체보다 좁고, API key보다 넓게 봐야 해. 로그인한 사람이 누구인지 표준 형식으로 확인하려면 보통 OpenID Connect가 붙고, OAuth는 그 앱이 어떤 리소스를 얼마만큼 쓸 수 있는지에 더 가까워. RFC 6749가 잡은 기본 역할도 resource owner, resource server, client, 권한 서버의 4개야.

어떻게 작동하나

흐름은 대체로 이렇게 나뉘어. 사용자는 권한 서버에서 로그인하고, client가 요청한 scope를 보고 허용해. 권한 서버는 code를 돌려주고, client는 그 code를 token endpoint에서 access token으로 바꿔. 그 뒤 client는 resource server의 API를 부를 때 token을 붙여.

이때 scope가 운영 판단의 중심이 돼. “캘린더 읽기”와 “캘린더 수정”은 같은 로그인 화면 뒤에 있어도 위험이 달라. Agent Identity가 있는 agent라면 더 세게 갈라 봐야 해. agent 자체 권한으로 API를 부르는지, 특정 사용자를 대신해 OAuth token을 받는지에 따라 감사 로그와 책임 경계가 달라져.

AI 도구에서도 이미 보이는 패턴이야. Claude Code Remote Control은 API key가 아니라 claude.ai OAuth가 필요하다고 안내해. Kimi Code나 Qwen Code 같은 개발 도구 문서에서도 OAuth 로그인, API key, 로컬 설정 파일이 서로 다른 인증 경로로 갈라져. 같은 “로그인했다”는 말이어도 실제 운영 표면은 꽤 달라.

왜 중요한가

AI agent가 외부 도구를 부르기 시작하면 OAuth는 UI 편의 기능이 아니라 권한 설계 문제가 돼. MCP 서버가 Gmail, Slack, Jira 같은 도구를 열어 주면 agent는 사람 대신 실행할 수 있는 권한을 갖게 돼. 이때 token scope가 너무 넓으면 프롬프트 인젝션이나 잘못된 도구 선택 하나로 읽기 전용이어야 할 작업이 쓰기 작업으로 바뀔 수 있어.

Activepieces 같은 자동화 서버도 마찬가지야. flow가 SaaS 계정에 붙을 때 OAuth를 쓰면 비밀번호를 저장하지 않아도 되지만, refresh token 보관, revoke 경로, 조직 계정의 app approval 정책은 여전히 남아. self-host 환경에서는 이 비밀값을 어디에 암호화하고 백업에서 어떻게 빼는지도 같이 봐야 해.

OAuth를 이해하면 기사에서 “API key 인증 불가”, “OAuth만 지원”, “사용자 위임 token”, “scope 제한” 같은 문장을 그냥 인증 세부사항으로 넘기지 않게 돼. 이 문장들이 실제로는 어떤 작업을 agent에게 맡길 수 있고, 사고가 났을 때 어디까지 revoke할 수 있는지를 가르는 기준이야.

주의해서 볼 점

첫째, bearer token은 들고 있는 쪽이 권한을 행사할 수 있어. RFC 6750도 token이 저장 중이든 전송 중이든 노출되지 않게 보호해야 한다고 잡아. 그래서 서버 로그, 브라우저 리다이렉트 URL, MCP tool output, 디버그 화면에 token이 섞이지 않는지 봐야 해.

둘째, 최신 OAuth 보안 관행은 예전 예제와 달라. RFC 9700은 2025년 1월 Best Current Practice로 나왔고, 권한 서버의 PKCE 지원을 요구해. native app 쪽 RFC 8252도 public native app client가 PKCE를 구현해야 한다고 둬. 오래된 “implicit flow면 충분하다” 식 예제를 그대로 가져오면 지금 기준과 어긋날 수 있어.

셋째, OAuth와 OpenID Connect를 섞어 말하면 판단이 흐려져. OAuth access token은 API 접근 권한을 말하고, OpenID Connect의 ID token은 사용자 신원 확인 쪽에 가까워. agent가 “사용자를 대신해 이메일을 읽는다”와 “이 사용자가 누구인지 확인한다”는 다른 문제야.

넷째, OAuth가 있어도 approval UI가 허술하면 소용없어. agent가 요청하는 scope, token 만료 시간, refresh token 회전, revoke 버튼, 로그에 남는 주체를 같이 봐야 해. 인증 방식 이름보다 이 다섯 가지가 실제 위험을 더 잘 보여 줘.