이 페이지는 Cloud Translation API를 통해 번역되었습니다.
Switch to English

모바일 및 데스크톱 앱용 OAuth 2.0

이 문서는 휴대 전화, 태블릿, 컴퓨터와 같은 기기에 설치된 애플리케이션이 Google의 OAuth 2.0 엔드 포인트를 사용하여 Google API에 대한 액세스를 승인하는 방법을 설명합니다.

OAuth 2.0을 통해 사용자는 사용자 이름, 비밀번호 및 기타 정보를 비공개로 유지하면서 특정 데이터를 애플리케이션과 공유 할 수 있습니다. 예를 들어 애플리케이션은 OAuth 2.0을 사용하여 사용자로부터 Google 드라이브에 파일을 저장할 수있는 권한을 얻을 수 있습니다.

설치된 앱은 개별 장치에 배포되며 이러한 앱은 비밀을 유지할 수 없다고 가정합니다. 사용자가 앱에있는 동안 또는 앱이 백그라운드에서 실행 중일 때 Google API에 액세스 할 수 있습니다.

이 인증 흐름은 웹 서버 응용 프로그램에 사용되는 것과 유사 합니다 . 주요 차이점은 설치된 앱이 시스템 브라우저를 열고 Google 인증 서버의 응답을 처리하기 위해 로컬 리디렉션 URI를 제공해야한다는 것입니다.

대안

모바일 앱의 경우 Android 또는 iOS 용 Google 로그인을 사용하는 것이 좋습니다. Google 로그인 클라이언트 라이브러리는 인증 및 사용자 승인을 처리하며 여기에 설명 된 하위 수준 프로토콜보다 구현이 더 간단 할 수 있습니다.

시스템 브라우저를 지원하지 않거나 TV, 게임 콘솔, 카메라 또는 프린터와 같이 입력 기능이 제한된 기기에서 실행되는 앱의 경우 TV 및 기기 용 OAuth 2.0 또는 기기 용 Google 로그인 참조하세요.

라이브러리 및 샘플

이 문서에 설명 된 OAuth 2.0 흐름을 구현하는 데 도움이되도록 다음 라이브러리와 샘플을 권장합니다.

전제 조건

프로젝트에 API 사용

Google API를 호출하는 모든 애플리케이션은 API Console에서 해당 API를 활성화해야합니다.

프로젝트에 API를 사용하려면 다음을 수행하십시오.

  1. Google API Console의 Open the API Library.
  2. If prompted, select a project, or create a new one.
  3. API Library은 제품군 및 인기도별로 그룹화 된 사용 가능한 모든 API를 나열합니다. 활성화하려는 API가 목록에 표시되지 않으면 검색을 사용하여 찾거나 해당 API가 속한 제품군에서 모두보기를 클릭합니다.
  4. 활성화 할 API를 선택한 다음 활성화 버튼을 클릭합니다.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

인증 자격 증명 만들기

OAuth 2.0을 사용하여 Google API에 액세스하는 모든 애플리케이션에는 Google의 OAuth 2.0 서버에 대한 애플리케이션을 식별하는 인증 자격 증명이 있어야합니다. 다음 단계에서는 프로젝트에 대한 자격 증명을 만드는 방법을 설명합니다. 그러면 애플리케이션은 사용자 인증 정보를 사용하여 해당 프로젝트에 대해 활성화 한 API에 액세스 할 수 있습니다.

  1. Go to the Credentials page.
  2. 사용자 인증 정보 만들기> OAuth 클라이언트 ID를 클릭합니다.
  3. 아래 섹션에서는 Google의 인증 서버가 지원하는 클라이언트 유형과 리디렉션 방법을 설명합니다. 애플리케이션에 권장되는 클라이언트 유형을 선택하고 OAuth 클라이언트의 이름을 지정한 다음 양식의 다른 필드를 적절하게 설정하십시오.

사용자 지정 URI 체계 (Android, iOS, UWP)

Android 앱, iOS 앱 및 UWP (유니버설 Windows 플랫폼) 앱에는 사용자 지정 URI 체계를 사용하는 것이 좋습니다.

기계적 인조 인간
  1. Android 애플리케이션 유형을 선택하십시오.
  2. OAuth 클라이언트의 이름을 입력하십시오. 이 이름은 클라이언트를 식별하기 위해 프로젝트의 Credentials page에 표시됩니다.
  3. Android 앱의 패키지 이름을 입력하십시오. 이 값은 앱 매니페스트 파일 에있는 <manifest> 요소package 속성에 정의됩니다.
  4. 앱 배포의 SHA-1 서명 인증서 지문을 입력합니다.
    • 앱에서 Google Play 앱 서명을 사용하는 경우 Play Console의 앱 서명 페이지에서 SHA-1 지문을 복사합니다.
    • 자체 키 저장소 및 서명 키를 관리하는 경우 Java에 포함 된 keytool 유틸리티를 사용하여 사람이 읽을 수있는 형식으로 인증서 정보를 인쇄하십시오. keytool 출력의 Certificate fingerprints 섹션에서 SHA1 값을 복사합니다. 자세한 정보는 Android 용 Google API 문서에서 클라이언트 인증 을 참조하십시오.
  5. 만들기를 클릭합니다.
iOS
  1. iOS 애플리케이션 유형을 선택하십시오.
  2. OAuth 클라이언트의 이름을 입력하십시오. 이 이름은 클라이언트를 식별하기 위해 프로젝트의 Credentials page에 표시됩니다.
  3. 앱의 번들 식별자를 입력하십시오. 번들 ID는 앱의 정보 속성 목록 리소스 파일 ( info.plist )에있는 CFBundleIdentifier 키의 값입니다. 값은 일반적으로 Xcode 프로젝트 편집기의 일반 창 또는 서명 및 기능 창에 표시됩니다. 번들 ID는 Apple의 App Store Connect 사이트 에있는 앱에 대한 앱 정보 페이지의 일반 정보 섹션에도 표시됩니다.
  4. (선택 과목)

    앱이 Apple의 App Store에 게시 된 경우 앱의 App Store ID를 입력합니다. Store ID는 모든 Apple App Store URL에 포함 된 숫자 문자열입니다.

    1. iOS 또는 iPadOS 기기에서 Apple App Store 앱 을 엽니 다.
    2. 앱을 검색합니다.
    3. 공유 버튼 (사각형 및 위쪽 화살표 기호)을 선택합니다.
    4. 링크 복사를 선택합니다.
    5. 링크를 텍스트 편집기에 붙여 넣습니다. App Store ID는 URL의 마지막 부분입니다.

      예 : https://apps.apple.com/app/google/id 284815942

  5. (선택 과목)

    팀 ID를 입력하십시오. 자세한 내용은 Apple 개발자 계정 설명서에서 팀 ID 찾기 를 참조하십시오.

  6. 만들기를 클릭합니다.
UWP
  1. 유니버설 Windows 플랫폼 애플리케이션 유형을 선택합니다.
  2. OAuth 클라이언트의 이름을 입력하십시오. 이 이름은 클라이언트를 식별하기 위해 프로젝트의 Credentials page에 표시됩니다.
  3. 앱의 12 자 Microsoft Store ID를 입력합니다. 이 값은 앱 관리 섹션의 앱 ID 페이지에있는 Microsoft 파트너 센터 에서 찾을 수 있습니다.
  4. 만들기를 클릭합니다.

UWP 앱의 경우 사용자 지정 URI 체계는 39자를 초과 할 수 없습니다.

루프백 IP 주소 (macOS, Linux, Windows 데스크톱)

이 URL을 사용하여 인증 코드를 받으려면 애플리케이션이 로컬 웹 서버에서 수신 중이어야합니다. 이는 전부는 아니지만 많은 플랫폼에서 가능합니다. 그러나 플랫폼에서 지원하는 경우 인증 코드를 얻기 위해 권장되는 메커니즘입니다.

앱이 승인 응답을 받으면 최상의 유용성을 위해 사용자에게 브라우저를 닫고 앱으로 돌아가도록 지시하는 HTML 페이지를 표시하여 응답해야합니다.

권장 사용법 macOS, Linux 및 Windows 데스크톱 (유니버설 Windows 플랫폼 아님) 앱
양식 값 애플리케이션 유형을 데스크톱 앱으로 설정합니다.

수동 복사 / 붙여 넣기

프로그래밍 방식 추출

액세스 범위 식별

범위를 사용하면 애플리케이션이 필요한 리소스에 대한 액세스 만 요청할 수 있으며 사용자는 애플리케이션에 부여하는 액세스 양을 제어 할 수 있습니다. 따라서 요청 된 범위의 수와 사용자 동의를 얻을 가능성 사이에 역관계가있을 수 있습니다.

OAuth 2.0 승인 구현을 시작하기 전에 앱에 액세스 권한이 필요한 범위를 식별하는 것이 좋습니다.

OAuth 2.0 API 범위 문서에는 Google API에 액세스하는 데 사용할 수있는 전체 범위 목록이 포함되어 있습니다.

OAuth 2.0 액세스 토큰 얻기

다음 단계는 애플리케이션이 Google의 OAuth 2.0 서버와 상호 작용하여 사용자를 대신하여 API 요청을 수행하기 위해 사용자의 동의를 얻는 방법을 보여줍니다. 사용자 승인이 필요한 Google API 요청을 실행하려면 애플리케이션에 이러한 동의가 있어야합니다.

1 단계 : 코드 검증 도구 및 챌린지 생성

Google은 설치된 앱 흐름을보다 안전하게 만들기 위해 PKCE ( Proof Key for Code Exchange ) 프로토콜을 지원합니다. 모든 권한 요청에 대해 고유 한 코드 검증자가 생성되고 "code_challenge"라는 변환 된 값이 권한 부여 코드를 얻기 위해 권한 부여 서버로 전송됩니다.

코드 검증 도구 만들기

code_verifier 는 예약되지 않은 문자 [AZ] / [az] / [0-9] / "-"/ "."를 사용하는 높은 엔트로피 암호화 임의 문자열입니다. / "_"/ "~", 최소 43 자, 최대 128 자.

코드 검증 도구는 값을 추측하는 것이 비현실적 이도록 충분한 엔트로피를 가져야합니다.

코드 챌린지 만들기

코드 챌린지를 만드는 두 가지 방법이 지원됩니다.

코드 챌린지 생성 방법
S256 (권장) 코드 챌린지는 코드 검증기의 Base64URL (패딩 없음) 인코딩 SHA256 해시입니다.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
평원 코드 챌린지는 위에서 생성 된 코드 검증기와 동일한 값입니다.
code_challenge = code_verifier

2 단계 : Google의 OAuth 2.0 서버에 요청 보내기

사용자 인증을 받으려면 https://accounts.google.com/o/oauth2/v2/auth 에서 Google 인증 서버에 요청을 보냅니다. 이 끝점은 활성 세션 조회를 처리하고 사용자를 인증하며 사용자 동의를 얻습니다. 끝점은 SSL을 통해서만 액세스 할 수 있으며 HTTP (비 SSL) 연결을 거부합니다.

권한 부여 서버는 설치된 애플리케이션에 대해 다음 쿼리 문자열 매개 변수를 지원합니다.

매개 변수
client_id 필수

애플리케이션의 클라이언트 ID입니다. 이 값은 API Console Credentials page에서 찾을 수 있습니다.

redirect_uri 필수

Google의 인증 서버가 앱에 응답을 보내는 방법을 결정합니다. 설치된 앱에 사용할 수있는 여러 리디렉션 옵션이 있으며 특정 리디렉션 방법을 염두에두고 인증 자격 증명 을 설정해야합니다.

이 값은 클라이언트의 API Console Credentials page에서 구성한 OAuth 2.0 클라이언트에 대해 승인 된 리디렉션 리디렉션 URI 중 하나와 정확히 일치해야합니다. 이 값이 승인 된 URI와 일치하지 않으면 redirect_uri_mismatch 오류가 발생합니다.

아래 표는 각 메소드에 대한 적절한 redirect_uri 매개 변수 값을 보여줍니다.

redirect_uri
사용자 지정 URI 체계 com.example.app : redirect_uri_path

또는

com.googleusercontent.apps.123 : redirect_uri_path
  • com.example.app 은 사용자가 제어하는 ​​도메인의 역 DNS 표기법입니다. 사용자 지정 체계에는 유효 기간이 포함되어야합니다.
  • com.googleusercontent.apps.123 은 클라이언트 ID의 역 DNS 표기법입니다.
  • redirect_uri_path/oauth2redirect 와 같은 선택적 경로 구성 요소입니다. 경로는 일반 HTTP URL과 다른 단일 슬래시로 시작해야합니다.
루프백 IP 주소 http://127.0.0.1: port 또는 http://[::1]: port

플랫폼에서 관련 루프백 IP 주소를 쿼리하고 사용 가능한 임의의 포트에서 HTTP 리스너를 시작합니다. port 를 앱이 수신하는 실제 포트 번호로 대체하십시오.

수동 복사 / 붙여 넣기 urn:ietf:wg:oauth:2.0:oob
프로그래밍 방식 추출 urn:ietf:wg:oauth:2.0:oob:auto
response_type 필수

Google OAuth 2.0 엔드 포인트가 인증 코드를 반환하는지 여부를 결정합니다.

설치된 애플리케이션의 code 로 매개 변수 값을 설정하십시오.

scope 필수

애플리케이션이 사용자를 대신하여 액세스 할 수있는 리소스를 식별하는 공백으로 구분 된 범위 목록입니다. 이 값은 Google이 사용자에게 표시하는 동의 화면을 알려줍니다.

범위를 사용하면 애플리케이션이 필요한 리소스에 대한 액세스 만 요청할 수 있으며 사용자는 애플리케이션에 부여하는 액세스 양을 제어 할 수 있습니다. 따라서 요청 된 범위의 수와 사용자 동의를 얻을 가능성 사이에는 반비례 관계가 있습니다.

code_challenge 추천

인증 코드 교환 중에 서버 측 챌린지로 사용될 인코딩 된 code_verifier 를 지정합니다. 이 매개 변수는 위에서 설명한 code_challenge 매개 변수와 함께 사용해야합니다. 자세한 내용은 위의 코드 도전 생성 섹션을 참조하세요.

code_challenge_method 추천

인증 코드 교환 중에 사용될 code_verifier 를 인코딩하는 데 사용 된 방법을 지정합니다. 이 매개 변수는 code_challenge 매개 변수와 함께 사용해야합니다. 의 값 code_challenge_method 디폴트 plain 포함 요청에 존재하지 않는 경우 code_challenge . 이 매개 변수에 대해 지원되는 유일한 값은 S256 또는 plain 입니다.

state 추천

애플리케이션이 권한 요청과 권한 서버의 응답 사이의 상태를 유지하기 위해 사용하는 문자열 값을 지정합니다. 서버는 사용자가 애플리케이션의 액세스 요청에 동의하거나 거부 한 후 redirect_uri 의 URL 조각 식별자 ( # )에 name=value 쌍으로 보내는 정확한 값을 반환합니다.

이 매개 변수는 사용자를 애플리케이션의 올바른 리소스로 안내하고, nonce를 전송하고, 교차 사이트 요청 위조를 완화하는 등 여러 목적으로 사용할 수 있습니다. redirect_uri 를 추측 할 수 있으므로 state 값을 사용하면 들어오는 연결이 인증 요청의 결과라는 확신을 높일 수 있습니다. 임의의 문자열을 생성하거나 쿠키의 해시 또는 클라이언트의 상태를 캡처하는 다른 값을 인코딩하는 경우 요청과 응답이 동일한 브라우저에서 시작되었는지 추가로 확인하여 교차 사이트와 같은 공격에 대한 보호를 제공하도록 응답의 유효성을 검사 할 수 있습니다. 위조 요청. state 토큰을 만들고 확인하는 방법에 대한 예제는 OpenID Connect 설명서를 참조하십시오.

login_hint 선택 과목

애플리케이션이 인증하려는 사용자를 알고있는 경우이 매개 변수를 사용하여 Google 인증 서버에 힌트를 제공 할 수 있습니다. 서버는 힌트를 사용하여 로그인 양식의 이메일 필드를 미리 채우거나 적절한 다중 로그인 세션을 선택하여 로그인 흐름을 단순화합니다.

매개 변수 값을 사용자의 Google ID와 동일한 이메일 주소 또는 sub 식별자로 설정합니다.

샘플 인증 URL

아래 탭은 다양한 리디렉션 URI 옵션에 대한 샘플 승인 URL을 보여줍니다.

URL은 redirect_uri 매개 변수의 값을 제외하고 동일합니다. URL에는 필수 response_typeclient_id 매개 변수와 선택적 state 매개 변수도 포함됩니다. 각 URL에는 가독성을 위해 줄 바꿈과 공백이 포함되어 있습니다.

사용자 지정 URI 체계

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

루프백 IP 주소

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

복사 붙여 넣기

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&
 client_id=client_id

프로그래밍 방식 추출

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
 client_id=client_id

3 단계 : Google에서 사용자에게 동의를 요청합니다.

이 단계에서 사용자는 애플리케이션에 요청 된 액세스 권한을 부여할지 여부를 결정합니다. 이 단계에서 Google은 사용자의 인증 자격 증명으로 액세스 권한을 요청하는 애플리케이션 및 Google API 서비스의 이름과 부여 할 액세스 범위 요약을 보여주는 동의 창을 표시합니다. 그런 다음 사용자는 애플리케이션에서 요청한 하나 이상의 범위에 대한 액세스 권한을 부여하거나 요청을 거부하는 데 동의 할 수 있습니다.

애플리케이션은 액세스 권한이 부여되었는지 여부를 나타내는 Google OAuth 2.0 서버의 응답을 기다리기 때문에이 단계에서 아무것도 할 필요가 없습니다. 그 응답은 다음 단계에서 설명됩니다.

4 단계 : OAuth 2.0 서버 응답 처리

애플리케이션이 인증 응답을 수신하는 방식 은 사용하는 리디렉션 URI 체계 에 따라 다릅니다. 체계에 관계없이 응답에는 인증 코드 ( code ) 또는 오류 ( error )가 포함됩니다. 예를 들어 error=access_denied 는 사용자가 요청을 거부했음을 나타냅니다.

사용자가 애플리케이션에 대한 액세스 권한을 부여하면 다음 단계에 설명 된대로 액세스 토큰 및 새로 고침 토큰에 대한 인증 코드를 교환 할 수 있습니다.

5 단계 : 새로 고침 및 액세스 토큰에 대한 인증 코드 교환

액세스 토큰에 대한 인증 코드를 교환하려면 https://oauth2.googleapis.com/token 엔드 포인트를 호출하고 다음 매개 변수를 설정 https://oauth2.googleapis.com/token .

필드
client_id API Console Credentials page에서 얻은 클라이언트 ID입니다.
client_secret API Console Credentials page에서 얻은 클라이언트 암호입니다.
code 초기 요청에서 반환 된 인증 코드입니다.
code_verifier 1 단계 에서 만든 코드 검증 도구입니다.
grant_type OAuth 2.0 사양에 정의 된대로이 필드의 값은 authorization_code 로 설정해야합니다.
redirect_uri 주어진 client_id 에 대해 API Console Credentials page에 프로젝트에 대해 나열된 리디렉션 URI 중 하나입니다.

다음 스 니펫은 샘플 요청을 보여줍니다.

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
grant_type=authorization_code

Google은 단기 액세스 토큰과 새로 고침 토큰이 포함 된 JSON 개체를 반환하여이 요청에 응답합니다.

응답에는 다음 필드가 포함됩니다.

필드
access_token 애플리케이션이 Google API 요청을 승인하기 위해 보내는 토큰입니다.
expires_in 액세스 토큰의 남은 수명 (초)입니다.
id_token 참고 : 이 속성은 요청에 openid , profile 또는 email 과 같은 ID 범위가 포함 된 경우에만 반환됩니다. 값은 사용자에 대한 디지털 서명 된 ID 정보가 포함 된 JWT (JSON Web Token)입니다.
refresh_token 새 액세스 토큰을 얻는 데 사용할 수있는 토큰입니다. 새로 고침 토큰은 사용자가 액세스를 취소 할 때까지 유효합니다. 새로 고침 토큰은 설치된 응용 프로그램에 대해 항상 반환됩니다.
scope 공백으로 구분되고 대소 문자를 구분하는 문자열 목록으로 표현되는 access_token 의해 부여 된 액세스 범위입니다.
token_type 반환 된 토큰 유형입니다. 이때이 필드의 값은 항상 Bearer 설정됩니다.

다음 스 니펫은 샘플 응답을 보여줍니다.

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Google API 호출

애플리케이션이 액세스 토큰을 얻은 후 API에 필요한 액세스 범위가 부여 된 경우 토큰을 사용하여 지정된 사용자 계정을 대신하여 Google API를 호출 할 수 있습니다. 이를 수행하려면 access_token 쿼리 매개 변수 또는 Authorization HTTP 헤더 Bearer 값을 포함하여 API 요청에 액세스 토큰을 포함합니다. 쿼리 문자열이 서버 로그에 표시되는 경향이 있기 때문에 가능하면 HTTP 헤더를 사용하는 것이 좋습니다. 대부분의 경우 클라이언트 라이브러리를 사용하여 Google API 호출을 설정할 수 있습니다 (예 : Drive Files API 호출 시).

OAuth 2.0 Playground 에서 모든 Google API를 사용해보고 범위를 볼 수 있습니다.

HTTP GET 예

Authorization: Bearer HTTP 헤더를 사용하는 drive.files 엔드 포인트 (Drive Files API)에 대한 호출은 다음과 같습니다. 고유 한 액세스 토큰을 지정해야합니다.

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

다음은 access_token 쿼리 문자열 매개 변수를 사용하여 인증 된 사용자에 대한 동일한 API에 대한 호출입니다.

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl

curl 명령 줄 응용 프로그램으로 이러한 명령을 테스트 할 수 있습니다. 다음은 HTTP 헤더 옵션 (권장)을 사용하는 예입니다.

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

또는 쿼리 문자열 매개 변수 옵션 :

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

액세스 토큰 새로 고침

액세스 토큰은 주기적으로 만료되고 관련 API 요청에 대해 유효하지 않은 자격 증명이됩니다. 토큰과 연결된 범위에 대한 오프라인 액세스를 요청한 경우 사용자에게 권한을 요청하지 않고 (사용자가없는 경우 포함) 액세스 토큰을 새로 고칠 수 있습니다.

액세스 토큰을 새로 고침하기 위해 애플리케이션은 다음 매개 변수를 포함하는 HTTPS POST 요청을 Google의 인증 서버 ( https://oauth2.googleapis.com/token )로 보냅니다.

필드
client_id API Console에서 얻은 클라이언트 ID입니다.
client_secret API Console에서 얻은 클라이언트 암호입니다. ( client_secret 은 Android, iOS 또는 Chrome 애플리케이션으로 등록 된 클라이언트의 요청에는 적용되지 않습니다.)
grant_type OAuth 2.0 사양에 정의 된 refresh_token 필드의 값은 refresh_token 으로 설정해야합니다.
refresh_token 인증 코드 교환에서 반환 된 새로 고침 토큰입니다.

다음 스 니펫은 샘플 요청을 보여줍니다.

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

사용자가 애플리케이션에 부여 된 액세스 권한을 취소하지 않는 한 토큰 서버는 새 액세스 토큰이 포함 된 JSON 개체를 반환합니다. 다음 스 니펫은 샘플 응답을 보여줍니다.

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

발급 될 새로 고침 토큰 수에는 제한이 있습니다. 클라이언트 / 사용자 조합 당 한도, 모든 클라이언트의 사용자 당 한도입니다. 새로 고침 토큰을 장기 저장소에 저장하고 유효한 상태로 유지되는 한 계속 사용해야합니다. 애플리케이션이 너무 많은 새로 고침 토큰을 요청하면 이러한 제한에 도달 할 수 있으며이 경우 이전 새로 고침 토큰이 작동을 중지합니다.

토큰 취소

경우에 따라 사용자는 응용 프로그램에 대한 액세스 권한을 취소 할 수 있습니다. 사용자는 계정 설정 을 방문하여 액세스를 취소 할 수 있습니다. 자세한 내용은 계정 지원 문서에 대한 액세스 권한이있는 타사 사이트 및 앱의 사이트 또는 앱 액세스 제거 섹션 을 참조하세요.

응용 프로그램이 주어진 액세스를 프로그래밍 방식으로 취소 할 수도 있습니다. 사용자가 구독을 취소하거나 애플리케이션을 제거하거나 앱에 필요한 API 리소스가 크게 변경된 경우 프로그래밍 방식 해지가 중요합니다. 즉, 제거 프로세스의 일부에는 이전에 애플리케이션에 부여 된 권한이 제거되었는지 확인하는 API 요청이 포함될 수 있습니다.

프로그래밍 방식으로 토큰을 취소하기 위해 애플리케이션은 https://oauth2.googleapis.com/revoke 요청을 https://oauth2.googleapis.com/revoke 토큰을 매개 변수로 포함합니다.

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

토큰은 액세스 토큰 또는 새로 고침 토큰 일 수 있습니다. 토큰이 액세스 토큰이고 해당하는 새로 고침 토큰이있는 경우 새로 고침 토큰도 취소됩니다.

해지가 성공적으로 처리 된 경우 응답의 HTTP 상태 코드는 200 입니다. 오류 조건의 경우 HTTP 상태 코드 400 이 오류 코드와 함께 반환됩니다.

추가 읽기

IETF Best Current Practice OAuth 2.0 for Native Apps 는 여기에 설명 된 많은 모범 사례를 설정합니다.