자격 증명 관리

첫 토큰을 발급받는 것은 시작에 불과합니다. OAuth 애플리케이션이 운영 환경에서 사용되기 시작하면, 그 자격 증명은 안전하게 저장되고, 때때로 교체되고, 문제가 생기면 신속하게 폐기될 수 있어야 합니다. 이는 보안 검토가 반드시 묻는 질문들입니다. 이 페이지는 이 세 가지와 함께, 유출된 토큰이 실제로 도달할 수 있는 범위, 그리고 유출이 의심될 때 해야 할 일을 다룹니다.

클라이언트 시크릿을 두어야 할 곳

환경 변수나 시크릿 매니저(AWS Secrets Manager, Vault 등)에 저장하세요, 소스 관리에는 절대 포함하지 말고, 코드와 함께 커밋되는 설정 파일에도 절대 넣지 마세요.
데스크톱 애플리케이션이나 브라우저 기반 클라이언트에는 절대 포함하지 마세요. 사용자의 기기에 설치되거나 브라우저에 제공되는 것은 바이너리나 번들을 검사당할 수 있으므로, 그 안에 포함된 시크릿은 배포되는 순간부터 공개된 것으로 취급해야 합니다.
바로 이런 이유로 Native Application 흐름은 클라이언트 시크릿을 전혀 발급하지 않습니다. 이 흐름은 시크릿을 기밀로 유지할 방법이 없는 데스크톱 및 CLI 통합을 위해 설계되었으며, 대신 PKCE(인가 코드에 연결된 요청별 증명)에 의존합니다. Authorization Code + 사용자 지정 HTTPS 리디렉션 흐름도 PKCE를 사용하며, 리디렉션 핸들러가 직접 관리하는 서버에서 실행되는 기밀 클라이언트에 한해서만 클라이언트 시크릿 추가를 허용합니다. 이 흐름을 브라우저 전용(SPA)으로 구현하는 경우, Native 흐름에 시크릿이 없는 것과 같은 이유로 시크릿을 설정하지 않아야 합니다. 시작하기: OAuth 플로 선택을 참고하세요.
Client Credentials는 서버 간 흐름이며 항상 시크릿이 필요합니다. 다른 서버 측 자격 증명과 동일한 규칙으로 저장하세요.

다운타임 없이 클라이언트 시크릿 교체하기

애플리케이션에서 Settings → OAuth를 통해 시크릿을 재생성하면 완전히 교체됩니다. 이전 시크릿과 새 시크릿이 동시에 유효한 기간은 없습니다. 여전히 이전 시크릿을 제시하는 호출자는 다음 토큰 또는 리프레시 요청부터 거부됩니다.

그렇다고 교체하는 순간 진행 중인 모든 요청이 실패하는 것은 아닙니다. 이미 발급된 액세스 토큰은 자체 TTL이 만료될 때까지 계속 작동합니다(약 1시간, 토큰 수명 주기 참고). 이는 그 토큰을 원래 발급한 시크릿에 이후 무슨 일이 일어나는지와 무관합니다. 오직 새로운 토큰 요청이나 리프레시만 새 시크릿을 필요로 합니다.

권장 전환 순서:

시크릿을 재생성합니다.
같은 변경 작업 안에서, 통합이 시크릿을 저장하는 모든 위치(설정, 시크릿 매니저, 모든 인스턴스나 워커)를 각각이 다음 번 토큰을 발급하거나 리프레시하기 전에 업데이트합니다.
새 시크릿으로 새 토큰 요청이 성공하는지 확인합니다.

모든 인스턴스를 원자적으로 업데이트할 수 없다면, 점진적인 롤아웃이 아니라 조율된 배포로 교체를 계획하세요. 이전 시크릿을 여전히 가지고 있는 인스턴스는 다음에 토큰이 필요할 때 우아하게 이전 시크릿으로 대체되는 것이 아니라 완전히 실패합니다.

액세스 폐기하기

액세스를 차단하는 방법은 두 가지이며, 둘 다 새로운 액세스를 막습니다.

Settings → Third-party access에서 개별 권한 부여를 취소합니다. 애플리케이션은 해당 권한 부여를 통해 더 이상 토큰을 갱신하거나 발급받을 수 없으며, 다른 사용자의 애플리케이션 사용에는 영향을 주지 않습니다.
Settings → OAuth에서 OAuth 애플리케이션을 삭제합니다. 모든 사용자에 대해 폐기됩니다. 해당 애플리케이션에 대해 더 이상 액세스 토큰이나 리프레시 토큰이 발급될 수 없고, 클라이언트 시크릿은 교체 후와 마찬가지로 작동을 멈춥니다. 클라이언트 자격 증명을 사용하는 애플리케이션이라면 같은 작업에서 애플리케이션의 서비스 사용자도 함께 비활성화됩니다.

권한 부여 취소, 애플리케이션 삭제, 시크릿 교체 모두 이미 발급된 액세스 토큰에는 영향을 주지 않으며, 강제로 만료시키지 않습니다. 해당 토큰은 원래의 스코프를 가진 채 자체 TTL이 만료될 때까지 사용 가능하다고 간주하세요. 활성 토큰에 무엇이 영향을 주고 무엇이 주지 않는지 전체 그림은 토큰 수명 주기를 참고하세요.

유출된 토큰이 도달할 수 있는 범위

유출된 토큰이 조직 전체의 유출을 의미하지는 않습니다. 3계층 보안 모델에 따라 이중으로 제한됩니다.

OAuth 스코프(계층 1): 발급 시점에 토큰에 고정됩니다. 이후 애플리케이션에서 스코프를 제거해도 이미 발급된 토큰은 줄어들지 않습니다. 이는 토큰이 다음 번 리프레시되거나 재발급될 때에만 적용됩니다.
서비스 사용자의 콘텐츠 액세스와 역할(계층 2와 3): 토큰의 서비스 사용자가 어떤 노드(조직, 디비전, 사이트)를 볼 수 있고 그곳에서 무엇을 할 수 있는지입니다. 스코프와 달리 이는 토큰에 고정되어 있지 않습니다. 요청이 들어올 때마다 현재 구성에 따라 평가됩니다.

실질적인 결론은 이렇습니다. 애플리케이션과 그 서비스 사용자를 처음부터 좁게 제한할수록, 유출된 토큰의 가치는 낮아집니다.

유출이 의심될 때

다음 순서로 진행하세요.

클라이언트 시크릿을 즉시 교체합니다 (Settings → OAuth → 해당 애플리케이션). 가장 빠르게 취할 수 있는 조치이며, 이전 시크릿으로의 새로운 토큰 또는 리프레시 요청을 즉시 차단합니다.
더 이상 사용할 계획이 없거나 시크릿 하나를 넘어서는 침해가 의심된다면 OAuth 애플리케이션을 삭제합니다. 클라이언트 자격 증명 애플리케이션의 경우 서비스 사용자도 비활성화되어 새 토큰 발급이 완전히 차단됩니다.
서비스 사용자의 콘텐츠 액세스를 제한하거나 제거합니다. 콘텐츠 및 역할 액세스(계층 2-3)는 토큰에 고정되는 것이 아니라 실시간으로 확인되므로, 이는 토큰의 TTL이 만료되기 전이라도 여전히 유효한 유출된 토큰이 도달할 수 있는 범위를 즉시 줄여줍니다.
토큰을 한 번 더 TTL 기간 동안 활성 상태로 취급합니다(약 1시간). 위의 어떤 단계도 이미 발급된 토큰을 강제로 만료시키지는 않습니다.
새 자격 증명을 발급합니다(새 시크릿이든 새 애플리케이션이든) 정상 사용을 재개하기 전에 통합을 업데이트합니다.

다음은?

TTL, 캐싱, 리프레시 동작에 대해서는 토큰 수명 주기
스코프, 콘텐츠 액세스, 역할이 어떻게 맞물리는지는 시작하기: 보안 모델