OAuth 2.0 ID 공급자 API

GitLab에 대한 서드파티 인증.

이 API를 사용하여 OAuth 2.0 프로토콜로 서드파티 서비스가 사용자의 GitLab 리소스에 접근할 수 있도록 허용합니다. 자세한 내용은 GitLab을 OAuth 2.0 인증 ID 공급자로 구성 을 참조하세요. 이 기능은 doorkeeper Ruby gem 을 기반으로 합니다. 교차 출처 리소스 공유 # 히스토리 CORS 사전 요청 지원이 GitLab 15.1에서 도입 되었습니다. 많은 /oauth 엔드포인트가 교차 출처 리소스 공유(CORS)를 지원합니다. GitLab 15.1부터 다음 엔드포인트도 CORS 사전 요청 을 지원합니다: /oauth/revoke /oauth/token /oauth/userinfo 사전 요청에는 특정 헤더만 사용할 수 있습니다: 단순 요청 에 나열된 헤더. Authorization 헤더. 예를 들어, X-Requested-With 헤더는 사전 요청에 사용할 수 없습니다. 지원되는 OAuth 2.0 플로우 # GitLab은 다음 인증 플로우를 지원합니다: PKCE(Proof Key for Code Exchange) 를 사용한 인증 코드 : 가장 안전합니다. PKCE 없이는 모바일 클라이언트에 클라이언트 비밀을 포함해야 하므로, 클라이언트 및 서버 앱 모두에 권장됩니다. 인증 코드 : 안전하고 일반적인 플로우. 안전한 서버 측 앱에 권장됩니다. 리소스 소유자 비밀번호 자격증명 : 안전하게 호스팅된 자사 서비스에만 사용해야 합니다. GitLab은 이 플로우 사용을 권장하지 않습니다. 기기 인증 부여 (GitLab 17.1 이상) 브라우저 접근이 없는 기기를 위한 안전한 플로우. 인증 플로우를 완료하려면 보조 기기가 필요합니다. OAuth 2.1 초안 사양은 암묵적 부여와 리소스 소유자 비밀번호 자격증명 플로우를 모두 제외합니다. 플로우의 작동 방식과 사용 사례에 맞는 플로우를 선택하려면 OAuth RFC 를 참조하세요. PKCE 유무에 관계없이 인증 코드 플로우를 사용하려면 먼저 사용자 계정의 /user_settings/applications 페이지를 통해 application 을 등록해야 합니다. 등록 시 적절한 범위를 활성화하여 application 이 접근할 수 있는 리소스 범위를 제한할 수 있습니다. 생성 후 application 자격증명(_애플리케이션 ID_와 클라이언트 비밀 )을 얻습니다. _클라이언트 비밀_은 반드시 안전하게 보관해야 합니다 . 애플리케이션 아키텍처가 허용하는 경우 _애플리케이션 ID_도 비밀로 유지하는 것이 유리합니다. GitLab의 범위 목록은 공급자 설명서 를 참조하세요. CSRF 공격 방지 # 리디렉션 기반 플로우를 보호 하기 위해 OAuth 사양은 /oauth/authorize 엔드포인트에 대한 각 요청에서 "사용자 에이전트에 안전하게 바인딩된 state 매개변수에 포함된 일회용 CSRF 토큰" 사용을 권장합니다. 이를 통해 CSRF 공격 을 방지할 수 있습니다. 프로덕션에서 HTTPS 사용 # 프로덕션 환경에서는 redirect_uri 에 HTTPS를 사용하세요. 개발