OAuth 2.0 ID 공급자 API

GitLab에 대한 서드파티 인증을 위한 OAuth 2.0 ID 공급자 API를 설명합니다.

이 API를 사용하면 서드파티 서비스가 OAuth 2.0 프로토콜로 사용자를 대신해 GitLab 리소스에 접근할 수 있습니다. 자세한 내용은 GitLab을 OAuth 2.0 인증 ID 공급자로 구성 을 참고합니다. 이 기능은 doorkeeper Ruby gem 을 기반으로 합니다. Cross-origin resource sharing # 다수의 /oauth 엔드포인트가 교차 출처 리소스 공유(CORS)를 지원합니다. 다음 엔드포인트는 CORS 사전 요청(preflight request) 도 지원합니다. /oauth/revoke /oauth/token /oauth/userinfo 사전 요청에는 일부 헤더만 사용할 수 있습니다. 단순 요청(simple request) 에 나열된 헤더. Authorization 헤더. 예를 들어 X-Requested-With 헤더는 사전 요청에 사용할 수 없습니다. 지원되는 OAuth 2.0 플로 # GitLab은 다음 인가 플로를 지원합니다. Authorization code with Proof Key for Code Exchange (PKCE) : 가장 안전합니다. PKCE가 없으면 모바일 클라이언트에 클라이언트 시크릿을 포함해야 합니다. 클라이언트 앱과 서버 앱 모두에 권장하는 플로입니다. Authorization code : 안전하고 널리 쓰이는 플로입니다. 보안이 확보된 서버 사이드 앱에 권장하는 방식입니다. Device Authorization Grant (GitLab 17.1 이상): 브라우저를 사용할 수 없는 기기를 위한 안전한 플로입니다. 인가 플로를 완료하려면 보조 기기가 필요합니다. OAuth 2.1 초안 명세는 Implicit grant 플로와 Resource Owner Password Credentials 플로를 모두 제외하고 있습니다. 각 플로의 동작 방식과 사용 사례에 맞는 선택 기준은 OAuth RFC 를 참고합니다. Authorization code 플로(PKCE 사용 여부와 무관)를 쓰려면 먼저 사용자 계정의 /user_settings/applications 페이지에서 application 을 등록해야 합니다. 등록 과정에서 적절한 스코프를 활성화하면 해당 application 이 접근할 수 있는 리소스 범위를 제한할 수 있습니다. 생성이 끝나면 다음 application 자격 증명을 받습니다. Application ID Client Secret Warning Client Secret은 안전하게 보관해야 합니다. 애플리케이션 아키텍처상 가능하다면 Application ID도 비공개로 유지합니다. GitLab의 스코프 목록은 공급자 문서 를 참고합니다. CSRF 공격 방지 # 리다이렉트 기반 플로를 보호 하기 위해 OAuth 명세는 "사용자 에이전트에 안전하게 바인딩된, state 파라미터로 전달되는 일회용 CSRF 토큰" 사용을 /oauth/authorize 엔드포인트로 보내는 모든 요청에 권장합니다. 이렇게 하면 CSRF 공격 을 방지할 수 있습니다. 프로덕션에서는 HTTPS