iOS 및 데스크톱 앱용 OAuth 2.0

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

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

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

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

라이브러리 및 샘플

iOS 앱의 경우 최신 버전의 Google 계정으로 로그인 iOS SDK를 사용하는 것이 좋습니다. SDK는 사용자 승인을 처리하며 이 가이드에 설명된 하위 수준 프로토콜보다 구현하기가 더 간단합니다.

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

기본 요건

프로젝트에 API 사용 설정

Google API를 호출하는 모든 애플리케이션은 API 콘솔에서 해당 API를 사용 설정해야 합니다.

프로젝트에 API를 사용 설정하려면 다음 단계를 따르세요.

1. Google API 콘솔에서 API 라이브러리를 엽니다.
2. 메시지가 표시되면 프로젝트를 선택하거나 새 프로젝트를 만듭니다.
3. API 라이브러리에는 사용 가능한 모든 API가 제품군과 인기도를 기준으로 그룹화되어 있습니다. 사용 설정하려는 API가 목록에 없는 경우 검색을 사용하여 찾거나 해당 제품군에서 모두 보기를 클릭합니다.
4. 사용 설정하려는 API를 선택한 다음 사용 설정 버튼을 클릭합니다.
5. 메시지가 표시되면 결제를 사용 설정합니다.
6. 메시지가 표시되면 API의 서비스 약관을 읽고 이에 동의합니다.

승인 사용자 인증 정보 만들기

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

1. 고객 페이지로 이동합니다.
2. 클라이언트 만들기를 클릭합니다.
3. 다음 섹션에서는 Google 승인 서버에서 지원하는 클라이언트 유형을 설명합니다. 애플리케이션에 권장되는 클라이언트 유형을 선택하고 OAuth 클라이언트 이름을 지정하고 양식의 다른 필드를 적절하게 설정합니다.

액세스 범위 식별

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

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는 예약되지 않은 문자 [A-Z] / [a-z] / [0-9] / '-' / '.' / '_' / '~'를 사용하는 엔트로피가 높은 암호화 무작위 문자열로, 최소 길이는 43자(영문 기준)이고 최대 길이는 128자(영문 기준)입니다.

코드 인증 도구는 값을 추측하기 어렵게 만들 수 있는 충분한 엔트로피를 가져야 합니다.

코드 챌린지 만들기

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

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) 연결을 거부합니다.

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

샘플 승인 URL

아래 탭에는 다양한 리디렉션 URI 옵션의 샘플 승인 URL이 표시됩니다.

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

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

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

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 엔드포인트를 호출하고 다음 매개변수를 설정합니다.

DPoP 사용은 선택사항이지만 보안 강화를 위해 사용하는 것이 좋습니다. DPoP의 보안은 비공개 키가 단일 기기로 제한되는 것에 의존합니다. TPM, 보안 Enclave 또는 기타 하드웨어 기반의 키 저장소를 사용하는 등 기기 외부로 복사할 수 없는 방식으로 저장하는 것이 좋습니다. DPoP를 사용하려면 애플리케이션이 토큰 엔드포인트에 대한 각 요청에 대해 새롭고 고유한 DPoP 증명 JWT를 생성하고 이를 HTTP 요청 헤더로 추가해야 합니다.

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

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

DPoP 증명 구성

다음 단계에서는 명령줄에서 OpenSSL을 사용하여 DPoP 증명을 구성하는 방법을 보여줍니다.

1. EC P-256 키 쌍을 생성합니다.

   openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
   openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

2. DPoP 헤더를 만듭니다.

   헤더에는 typ, alg, jwk (공개 키) 클레임이 포함되어야 합니다. x 및 y 값은 EC 공개 키의 Base64Url로 인코딩된 좌표입니다. 이 JSON을 Base64Url로 인코딩합니다.

   {
     "typ":"dpop+jwt",
     "alg":"ES256",
     "jwk": {
       "kty":"EC",
       "x":"YOUR_PUBLIC_KEY_X",
       "y":"YOUR_PUBLIC_KEY_Y",
       "crv":"P-256"
     }
   }

3. DPoP 페이로드 만들기:

   페이로드에는 jti (요청의 고유 식별자), htm (HTTP 메서드, 예: POST), htu(HTTP URI, 예: https://oauth2.googleapis.com/token), iat (발급 시간)가 포함되어야 합니다. 이전 요청에 대한 응답의 DPoP-Nonce 헤더에서 서버로부터 nonce를 받은 경우 nonce 클레임에 해당 nonce 값을 포함해야 합니다. nonce 클레임은 승인 코드 교환에 선택사항이며 이전에 DPoP-Nonce 헤더를 수신한 경우에만 사용됩니다. 이 JSON을 Base64Url로 인코딩합니다.

   {
     "jti":"JTI_VALUE",
     "htm":"POST",
     "htu":"https://oauth2.googleapis.com/token",
     "iat":YOUR_JWT_ISSUED_TIME,
     "nonce":"SERVER_PROVIDED_NONCE"
   }

   jti 값은 교환 유형에 따라 다릅니다.

   • 승인 코드 교환의 경우 jti는 승인 코드의 Base64Url로 인코딩된 SHA256 해시("jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))")여야 합니다.
   • 갱신 토큰 교환의 경우 jti는 요청별 고유 식별자("jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER")여야 합니다.
4. thought 증명에 서명:

   인코딩된 헤더와 페이로드를 마침표 (.)로 연결한 다음 ES256을 사용하여 비공개 키로 결과에 서명합니다. JWS에서는 서명이 원시 R | S 연결 형식 (P-256의 경우 64바이트)이어야 합니다. OpenSSL을 직접 사용하는 경우 기본 ASN.1 DER 인코딩 서명을 이 원시 형식으로 변환해야 합니다.

교환에 성공하면 토큰이 포함된 200 OK 응답이 표시됩니다. 교환 중에 유효한 DPoP 증명이 사용되면 Google에서 반환하는 갱신 토큰은 키에 DPoP 바인딩되지만 액세스 토큰은 DPoP 바인딩되지 않습니다. 액세스 토큰은 DPoP가 아닌 Bearer의 token_type을 유지합니다. 또한 Google은 응답에 DPoP-Nonce HTTP 헤더를 반환합니다. 클라이언트는 이 nonce를 캐시하고 후속 요청 (예: 갱신 토큰을 새 액세스 토큰으로 교환하거나 DPoP로 보호되는 API를 호출할 때)에서 DPoP 증명의 nonce 클레임에 포함해야 합니다. 이 조기 발급된 nonce를 사용하면 다음 요청에서 추가 왕복 실패 (use_dpop_nonce)를 방지할 수 있습니다.

DPoP 바인딩 갱신 토큰으로 이루어진 토큰 교환 요청에는 DPoP 증명이 포함되어야 합니다.

DPoP 헤더가 예상 시점에 누락되거나 유효하지 않거나 증명에서 토큰에 바인딩된 키와 다른 키를 사용하는 경우 교환 실패가 발생합니다. 이러한 경우 서버는 400 Bad Request 오류를 반환합니다. DPoP 증명에 일치하지 않는 htm 또는 htu 클레임, 만료된 iat, 재사용된 jti 또는 잘못된 서명이 있는 경우 Google은 invalid_dpop_proof 오류 코드를 반환합니다. 갱신 토큰 교환 중과 같이 DPoP nonce가 필요하고 DPoP 증명에 nonce 클레임이 누락되었거나 nonce 값이 서버에서 허용되지 않는 경우 (예: 만료되었거나 이미 사용되었거나 잘못됨) Google은 use_dpop_nonce 오류 코드와 함께 후속 요청에서 사용할 수 있는 새 nonce가 포함된 DPoP-Nonce HTTP 헤더를 반환합니다. 다른 실패는 invalid_grant를 반환할 수 있습니다.

Google은 단기 액세스 토큰과 갱신 토큰이 포함된 JSON 객체를 반환하여 이 요청에 응답합니다.

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

다음 스니펫은 DPoP를 사용할 때 성공적인 응답 헤더 및 본문의 샘플을 보여줍니다.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

6단계: 사용자가 부여한 범위 확인하기

여러 권한 (범위)을 요청하는 경우 사용자가 앱에 모든 권한에 대한 액세스 권한을 부여하지 않을 수 있습니다. 앱은 실제로 부여된 범위를 확인하고 일부 권한이 거부된 상황을 정상적으로 처리해야 합니다. 일반적으로 거부된 범위에 의존하는 기능을 사용 중지하는 방식으로 처리합니다.

하지만 예외도 있습니다. 도메인 전체 권한 위임이 있는 Google Workspace Enterprise 앱 또는 신뢰할 수 있음으로 표시된 앱은 세분화된 권한 동의 화면을 우회합니다. 이러한 앱의 경우 사용자에게 세분화된 권한 동의 화면이 표시되지 않습니다. 대신 앱은 요청된 모든 범위를 수신하거나 아무것도 수신하지 않습니다.

자세한 내용은 세분화된 권한을 처리하는 방법을 참고하세요.

사용자가 애플리케이션에 특정 범위에 대한 액세스 권한을 부여했는지 확인하려면 액세스 토큰 응답의 scope 필드를 검사합니다. access_token에 의해 부여된 액세스 범위로, 공백으로 구분된 대소문자를 구분하는 문자열 목록으로 표현됩니다.

예를 들어 다음 샘플 액세스 토큰 응답은 사용자가 애플리케이션에 읽기 전용 Drive 활동 및 캘린더 일정 권한에 대한 액세스 권한을 부여했음을 나타냅니다.

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.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 플레이그라운드에서 모든 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)로 전송합니다.

DPoP 사용은 선택사항이지만 보안 강화를 위해 사용하는 것이 좋습니다. 갱신 토큰과 함께 DPoP를 사용하려면 애플리케이션에서 토큰 엔드포인트에 대한 각 요청에 대해 새롭고 고유한 DPoP 증명 JWT를 생성해야 합니다. 이 증명은 초기 승인 코드 교환 중에 사용된 것과 동일한 비공개 키로 서명되어야 합니다. 애플리케이션은 증명을 HTTP 요청 헤더로 추가합니다.

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

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

갱신 토큰과 함께 DPoP를 사용하려면 요청에 대해 새롭고 고유한 DPoP 증명 JWT를 생성해야 합니다. 키 쌍을 생성하고 JWT를 구성하는 방법에 관한 단계별 안내는 DPoP 증명 구성을 참고하세요.

교환이 성공하면 새 액세스 토큰이 포함된 200 OK 응답이 표시됩니다. DPoP를 사용하는 경우 token_type는 Bearer입니다. 성공 응답은 갱신 토큰의 DPoP 증명이 수락되었음을 확인합니다. Google은 응답에 새 DPoP-Nonce HTTP 헤더를 반환할 수도 있습니다. 반환된 경우 클라이언트는 이 nonce를 캐시하고 후속 요청에서 DPoP 증명의 nonce 클레임에 포함해야 합니다.

DPoP 헤더가 누락되었거나 잘못되었거나 잘못된 키를 사용하는 경우 교환 실패가 발생합니다. 특정 DPoP 오류 코드 및 nonce 처리에 관한 자세한 내용은 교환 실패를 참고하세요.

다음 스니펫은 DPoP를 사용할 때 성공적인 응답 헤더 및 본문의 샘플을 보여줍니다.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

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

발급되는 갱신 토큰 수에는 제한이 있습니다. 클라이언트/사용자 조합당 한도와 모든 클라이언트의 사용자당 한도가 있습니다. 갱신 토큰은 장기 스토리지에 저장하고 유효한 동안 계속 사용해야 합니다. 애플리케이션에서 갱신 토큰을 너무 많이 요청하면 이러한 한도에 도달할 수 있으며, 이 경우 이전 갱신 토큰이 작동하지 않게 됩니다.

토큰 취소

경우에 따라 사용자가 애플리케이션에 부여된 액세스 권한을 취소할 수 있습니다. 사용자는 계정 설정을 방문하여 액세스 권한을 취소할 수 있습니다. 자세한 내용은 내 계정에 액세스할 수 있는 서드 파티 사이트 및 앱의 사이트 또는 앱 액세스 권한 삭제 섹션 지원 문서를 참고하세요.

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

프로그래매틱 방식으로 토큰을 취소하려면 애플리케이션에서 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가 오류 코드와 함께 반환됩니다.

앱 리디렉션 방법

앱 보호

시간 기반 액세스

시간 기반 액세스를 사용하면 사용자가 제한된 기간 동안 앱에 데이터 액세스 권한을 부여하여 작업을 완료할 수 있습니다. 시간 기반 액세스는 동의 흐름 중에 일부 Google 제품에서 사용할 수 있으며, 사용자에게 제한된 기간 동안 액세스 권한을 부여할 수 있는 옵션을 제공합니다. 한 가지 예로 데이터를 일회성으로 전송할 수 있는 Data Portability API가 있습니다.

사용자가 애플리케이션에 시간 기반 액세스 권한을 부여하면 지정된 기간이 지난 후 갱신 토큰이 만료됩니다. 특정 상황에서는 갱신 토큰이 더 일찍 무효화될 수 있습니다. 자세한 내용은 이러한 사례를 참고하세요. 이러한 경우 승인 코드 교환 응답에서 반환되는 refresh_token_expires_in 필드는 갱신 토큰이 만료될 때까지 남은 시간을 나타냅니다.

추가 자료

IETF Best Current Practice 네이티브 앱용 OAuth 2.0는 여기에 설명된 많은 권장사항을 설정합니다.