콘텐츠로 이동

OAuth2 (권한 위임)

우리가 Notion이나 Google 같은 외부 서비스의 데이터를 읽으려면 그쪽 비밀번호를 알아야 한다고 생각해 보세요. 그건 위험할 뿐 아니라 좋은 설계도 아니에요. OAuth 2.0은 비밀번호를 직접 주고받지 않고도, 필요한 권한만 골라 위임받는 표준 방식이에요. 고객이 우리에게 "내 데이터 일부를 이 앱이 봐도 돼"라고 제한된 범위로 허락해 주는 거죠.

여러 흐름(grant type)이 있지만, 우리가 주로 만나는 건 사용자 허락을 받는 방식과 서비스 간 신뢰 방식이에요. 각각을 아래에서 나눠 살펴볼게요.

처음에는 토큰이 여러 개 나오는 게 헷갈릴 수 있어요. 그럴 땐 "사용자가 허락했다는 증거로 앱이 API를 부르는 자격증을 받는다" 정도로 이해하면 돼요. 자세한 절차는 아래에서 이어져요.

하위 챕터

  • 그랜트 타입 — 권한을 얻는 네 가지 방식(인가코드/PKCE/클라이언트)
  • 토큰 — 액세스 토큰과 리프레시 토큰
  • 스코프 — "얼마나" 허락할지 정하는 권한 위임 범위

핵심 개념

권한 부여(Authorization)와 위임. OAuth는 "로그인(인증)"보다 "접근 허락(인가)"을 다룬다는 점이 중요해요. 사용자가 직접 허락을 내리고, 그 허락 범위는 스코프(scope)로 좁게 잡아요. Notion 문서 읽기만 허락하면 쓰기는 막아 둘 수 있는 식이죠. 이렇게 범위를 제한하는 덕에, 토큰이 유출돼도 피해 범위가 줄어요.

권한 부여 흐름. 대표적인 흐름이 Authorization Code 방식이에요. 사용자가 인증 서버에 로그인해 동의하면, 그 서버가 임시 코드를 주고, 우리 앱이 그 코드를 다시 교환해 액세스 토큰을 받아요. 비밀번호는 한 번도 우리 손을 거치지 않죠.

이 흐름에서 사용자의 로그인 화면은 늘 인증 서버(예: Notion, Google)가 제공해요. 우리는 그 화면 뒤로 리다이렉트만 시키고 결과 코드를 받는 역할이에요.

사용자 → 인증 서버 로그인·동의 → 임시 코드 → 앱 → 액세스 토큰 교환 → API 호출

액세스 토큰·리프레시 토큰. 액세스 토큰은 유효기간이 짧고, 그 다음에 오는 리프레시 토큰으로 액세스 토큰을 다시 발급받아요. 짧은 수명 덕에 토큰이 유출돼도 피해 범위를 줄일 수 있어요.

서비스 간 통신. 사용자의 직접 허락 없이, 시스템의 신뢰 관계만으로 권한을 주는 흐름(client credentials)도 있어요. 백엔드끼리 통신할 때 쓰죠.

사용 사례 / 실제 적용

외부 서비스 연동이 대표적이에요. 고객이 Notion 계정을 연결하면, 우리는 그쪽 비밀번호를 모른 채 액세스 토큰으로 제한된 범위의 데이터만 읽어요. 그 토큰은 주고받는 과정에서 암호화하고, 이후 서비스 간 인증에는 짧은 수명의 토큰을 쓰도록 설계해요.

여기서 챙겨야 할 건 스코프를 최소화하고, 리프레시 토큰을 안전하게 보관하며, 토큰 만료·폐기를 제대로 처리하는 거예요. 고객이 연결을 해제하면 우리가 가진 토큰까지 함께 무효화돼야 하죠.

더 알아보기