OAuth로 Google 계정 연결

계정은 업계 표준 OAuth 2.0 암시적 흐름 및 승인 코드 흐름을 사용하여 연결됩니다. 서비스가 OAuth 2.0을 준수하는 승인토큰 교환 엔드포인트를 지원해야 합니다.

암시적 흐름에서는 Google이 사용자의 브라우저에서 승인 엔드포인트를 엽니다. 로그인에 성공하면 장기 액세스 토큰을 Google에 반환합니다. 이제 Google에서 전송하는 모든 요청에 이 액세스 토큰이 포함됩니다.

승인 코드 흐름에는 두 개의 엔드포인트가 필요합니다.

  • 아직 로그인하지 않은 사용자에게 로그인 UI를 표시하는 승인 엔드포인트입니다. 승인 엔드포인트는 요청된 액세스에 대한 사용자의 동의를 기록하기 위해 단기 승인 코드도 만듭니다.

  • 두 가지 유형의 교환을 담당하는 토큰 교환 엔드포인트:

    1. 승인 코드를 사용 기간이 긴 갱신 토큰 및 사용 기간이 짧은 액세스 토큰으로 교환합니다. 이 교환은 사용자가 계정 연결 흐름을 진행할 때 발생합니다.
    2. 장기 갱신 토큰을 단기 액세스 토큰으로 교환합니다. 이 교환은 만료된 액세스 토큰으로 인해 Google에 새 액세스 토큰이 필요할 때 발생합니다.

OAuth 2.0 흐름 선택

암시적 흐름은 구현하기가 더 간단하지만 암시적 흐름에서 발급된 액세스 토큰은 만료되지 않도록 하는 것이 좋습니다. 이는 암시적 흐름으로 토큰이 만료된 후 사용자가 계정을 다시 연결해야 하기 때문입니다. 보안상의 이유로 토큰 만료가 필요한 경우에는 승인 코드 흐름을 대신 사용하는 것이 좋습니다.

디자인 가이드라인

이 섹션에서는 OAuth 연결 흐름을 위해 호스팅하는 사용자 화면에 대한 디자인 요구사항과 권장사항을 설명합니다. Google 앱에서 호출하면 플랫폼에서 사용자에게 Google 로그인 페이지와 계정 연결 동의 화면을 표시합니다. 사용자가 계정 연결에 동의하면 Google 앱으로 다시 리디렉션됩니다.

이 그림은 사용자가 Google 계정을 인증 시스템에 연결하는 단계를 보여줍니다. 첫 번째 스크린샷은 플랫폼에서 사용자가 시작한 연결을 보여줍니다. 두 번째 이미지는 사용자의 Google 로그인을 보여주며 세 번째 이미지는 Google 계정을 앱과 연결하기 위한 사용자 동의 및 확인을 보여줍니다. 최종 스크린샷은 Google 앱에서 성공적으로 연결된 사용자 계정을 보여줍니다.
그림 1. 계정 연결 사용자의 Google 로그인 및 동의 화면

요구사항

  1. 사용자의 계정이 Google Home 또는 Google 어시스턴트와 같은 특정 Google 제품이 아닌 Google에 연결된다고 안내해야 합니다.

권장사항

다음을 수행하는 것이 좋습니다.

  1. Google 개인정보처리방침을 표시합니다. 동의 화면에 Google 개인정보처리방침 링크를 포함합니다.

  2. 공유할 데이터 Google에서 필요로 하는 데이터와 그 이유를 사용자에게 명확하고 간결한 언어로 전달하세요.

  3. 명확한 클릭 유도 문구 '동의 및 연결'과 같은 명확한 클릭 유도 문구를 동의 화면에 표시합니다. 이는 사용자가 계정을 연결하기 위해 Google과 공유해야 하는 데이터를 이해해야 하기 때문입니다.

  4. 취소 기능 사용자가 연결하지 않기로 선택한 경우 뒤로 돌아가거나 취소할 수 있는 방법을 제공합니다.

  5. 명확한 로그인 절차. 사용자에게 사용자 이름 및 비밀번호 입력란이나 Google 계정으로 로그인과 같이 Google 계정에 로그인하는 명확한 방법이 제공되어야 합니다.

  6. 연결 해제 기능. 사용자가 연결을 해제할 수 있는 메커니즘(예: 플랫폼의 계정 설정 URL)을 제공합니다. 또는 사용자가 연결된 계정을 관리할 수 있는 Google 계정 링크를 포함할 수 있습니다.

  7. 사용자 계정을 변경할 수 있는 기능 사용자가 계정을 전환할 수 있는 방법을 제안합니다. 이는 사용자가 여러 계정을 사용하는 경향이 있는 경우에 특히 유용합니다.

    • 사용자가 계정을 전환하려면 동의 화면을 닫아야 하는 경우 사용자가 OAuth 연결암시적 흐름으로 원하는 계정에 로그인할 수 있도록 복구 가능한 오류를 Google에 전송합니다.
  8. 로고를 포함합니다. 동의 화면에 회사 로고를 표시합니다. 스타일 가이드라인에 따라 로고를 배치합니다. Google 로고도 표시하려면 로고 및 상표를 참고하세요.

프로젝트 만들기

계정 연결을 사용할 프로젝트를 만들려면 다음 단계를 따르세요.

  1. 프로젝트 만들기를 클릭합니다.
  2. 이름을 입력하거나 생성된 추천을 수락합니다.
  3. 나머지 필드를 확인하거나 수정합니다.
  4. 만들기를 클릭합니다.

프로젝트 ID를 확인하려면 다음 단계를 따르세요.

  1. 방문 페이지의 표에서 프로젝트를 찾습니다. 프로젝트 ID는 ID 열에 표시됩니다.

Google 계정 연결 프로세스에는 사용자에게 데이터 액세스를 요청하는 애플리케이션, 요청하는 데이터의 종류, 적용되는 약관을 알려주는 동의 화면이 포함됩니다. Google API 클라이언트 ID를 생성하기 전에 OAuth 동의 화면을 구성해야 합니다.

  1. Google API 콘솔의 OAuth 동의 화면 페이지를 엽니다.
  2. 메시지가 표시되면 방금 만든 프로젝트를 선택합니다.
  3. 'OAuth 동의 화면' 페이지에서 양식을 작성하고 '저장' 버튼을 클릭합니다.

    애플리케이션 이름: 동의를 요청하는 애플리케이션의 이름입니다. 이름은 애플리케이션을 정확하게 반영해야 하며 사용자가 다른 곳에서 보는 애플리케이션 이름과 일치해야 합니다. 애플리케이션 이름은 계정 연결 동의 화면에 표시됩니다.

    애플리케이션 로고: 사용자가 앱을 인식하는 데 도움이 되는 동의 화면의 이미지입니다. 로고는 계정 연결 동의 화면과 계정 설정에 표시됩니다.

    지원 이메일: 사용자가 동의에 대해 문의할 수 있습니다.

    Google API 범위: 범위를 사용하면 애플리케이션이 사용자의 비공개 Google 데이터에 액세스할 수 있습니다. Google 계정 연결 사용 사례의 경우 기본 범위 (이메일, 프로필, openid)로 충분하며 민감한 범위를 추가할 필요가 없습니다. 일반적으로 액세스가 필요한 시점에 미리 요청하는 대신 점진적으로 범위를 요청하는 것이 좋습니다. 자세히 알아보기

    승인된 도메인: 나와 내 사용자를 보호하기 위해 Google에서는 OAuth를 사용하여 인증하는 애플리케이션만 승인된 도메인을 사용할 수 있도록 허용합니다. 애플리케이션의 링크는 승인된 도메인에서 호스팅되어야 합니다. 자세히 알아보기

    애플리케이션 홈페이지 링크: 애플리케이션의 홈페이지입니다. 승인된 도메인에서 호스팅해야 합니다.

    애플리케이션 개인정보처리방침 링크: Google 계정 연결 동의 화면에 표시됩니다. 승인된 도메인에서 호스팅해야 합니다.

    애플리케이션 서비스 약관 링크 (선택사항): 승인된 도메인에서 호스팅되어야 합니다.

    그림 1. 가상 애플리케이션 Tunery의 Google 계정 연결 동의 화면

  4. '인증 상태'를 확인합니다. 애플리케이션에 인증이 필요한 경우 '인증을 위해 제출' 버튼을 클릭하여 인증을 위해 애플리케이션을 제출합니다. 자세한 내용은 OAuth 인증 요구사항을 참고하세요.

OAuth 서버 구현

授权代码流程的 OAuth 2.0 服务器实现包括 两个端点,您的服务会通过 HTTPS 提供这两个端点。第一个端点 是授权端点,负责查找或获取 就数据访问征求用户意见。授权端点会提供一个 尚未登录的用户的登录界面,并记录同意情况 请求的访问权限。第二个端点是令牌交换端点, 用于获取加密字符串(称为令牌),以授权用户 访问您的服务。

当 Google 应用需要调用您的某个服务的 API 时,Google 会使用 将这些端点组合在一起,以获取用户调用这些 API 的权限 。

由 Google 发起的 OAuth 2.0 授权代码流程会话包含 以下流程:

  1. Google 会在用户的浏览器中打开您的授权端点。如果流 在用户通过纯语音设备上针对某个 Action 启动,Google 会将 将代码执行到手机上
  2. 用户登录(如果尚未登录),并授予 Google 以下权限: 访问您的 API 访问其数据(如果尚未授权)。
  3. 您的服务会创建授权代码并将其返回给 Google。待办事项 因此,请使用授权代码将用户的浏览器重定向回 Google。 附件。
  4. Google 会将授权代码发送到您的令牌交换端点, 验证代码的真实性并返回访问令牌刷新令牌。访问令牌是一个短期有效的令牌 作为访问 API 的凭据。刷新令牌长期有效 Google 可以存储该令牌,以便在用户首次访问该令牌时, 过期。
  5. 在用户完成账号关联流程后, 从 Google 发送的请求中包含访问令牌。

处理授权请求

需要使用 OAuth 2.0 授权代码执行账号关联的情况 流程中,Google 会通过请求将用户发送到您的授权端点 包含以下参数:

授权端点参数
client_id 您分配给 Google 的客户 ID。
redirect_uri 此请求的响应发送到的网址。
state 将一个在 重定向 URI。
scope 可选:一组以空格分隔的范围字符串,用于指定 Google 请求授权的数据
response_type 要在响应中返回的值的类型。对于 OAuth 2.0 授权代码流程中,响应类型始终为 code
user_locale “Google 账号语言设置” RFC5646 格式,用于将您的内容本地化为用户首选语言。

例如,如果您的授权端点位于 https://myservice.example.com/auth 时,请求可能如下所示:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

为了让授权端点能够处理登录请求,请执行以下操作 步骤:

  1. 验证 client_id 是否与您分配给 Google 的 Client ID 匹配,以及 redirect_uri 与 Google 为您的服务提供的重定向网址是否匹配。这些检查对于防止 访问意外或配置错误的客户端应用。如果你支持多种 OAuth 2.0 流程,还应确认 response_type 是否为 code
  2. 检查用户是否已登录您的服务。如果用户没有登录, 完成服务的登录或注册流程。
  3. 生成授权代码,以供 Google 用于访问您的 API。 授权代码可以是任何字符串值,但它必须是唯一的 代表用户、令牌对应的客户端以及代码的有效期 而且不可猜测出来。您通常需要进行授权 会在大约 10 分钟后过期。
  4. 确认 redirect_uri 参数指定的网址包含 以下表单:
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
      https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
      
  5. 将用户的浏览器重定向到 redirect_uri 参数。添加您在 以及您在重定向时返回未经修改的原始状态值 方法是附加 codestate 参数。以下是 生成的网址示例:
    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

处理令牌交换请求

您的服务的令牌交换端点负责处理两种令牌 广告交易平台:

  • 交换访问令牌和刷新令牌的授权代码
  • 用刷新令牌换取访问令牌

令牌交换请求包含以下参数:

令牌交换端点参数
client_id 用于将请求来源标识为 Google 的字符串。此字符串必须 在您的系统中注册为 Google 的唯一标识符。
client_secret 您在 Google 中为您的服务注册的密钥字符串。
grant_type 所交换的令牌的类型。是 authorization_coderefresh_token
code 如果值为 grant_type=authorization_code,则此参数为 Google 通过您的登录或令牌交换收到的代码 端点。
redirect_uri 如果值为 grant_type=authorization_code,则此参数为 初始授权请求中使用的网址。
refresh_token 如果值为 grant_type=refresh_token,则此参数为 刷新令牌 Google 从您的令牌交换端点收到的令牌。
交换访问令牌和刷新令牌的授权代码

用户登录且您的授权端点返回一个短期有效的 授权代码发送给 Google,Google 会向您的令牌交换发送请求 端点使用授权代码交换访问令牌和刷新 令牌。

对于这些请求,grant_type 的值为 authorization_code, 的 code 值是您先前授予的授权代码的值 。以下是发送 访问令牌和刷新令牌的授权代码:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

要将授权代码交换为访问令牌和刷新令牌,您的 令牌交换端点通过执行以下命令来响应 POST 请求: 步骤:

  1. 验证 client_id 是否将请求来源标识为已获授权的请求来源 来源,并且 client_secret 与预期值匹配。
  2. 请确认授权代码有效且未过期, 请求中指定的客户端 ID 与 授权代码。
  3. 确认 redirect_uri 参数指定的网址完全相同 初始授权请求中使用的值。
  4. 如果您无法验证上述所有条件,则返回 HTTP 正文为 {"error": "invalid_grant"} 的 400 Bad Request 错误。
  5. 否则,使用授权代码中的用户 ID 来生成刷新 令牌和访问令牌。这些标记可以是任何字符串值, 必须唯一地代表用户和令牌对应的客户端, 不得被猜到对于访问令牌,请记录 令牌,通常是在您发出令牌一个小时后。 刷新令牌不会过期。
  6. 在 HTTPS 响应的正文中返回以下 JSON 对象:
    {
    "token_type": "Bearer",
    "access_token": "ACCESS_TOKEN",
    "refresh_token": "REFRESH_TOKEN",
    "expires_in": SECONDS_TO_EXPIRATION
    }

Google 会存储用户的访问令牌和刷新令牌,并存储相关记录 访问令牌的有效期。访问令牌过期后,Google 会使用 刷新令牌,以从令牌交换端点获取新的访问令牌。

用刷新令牌换取访问令牌

访问令牌过期后,Google 会向您的令牌交换发送请求 端点将刷新令牌交换为新的访问令牌。

对于这些请求,grant_type 的值为 refresh_token,值 “refresh_token”是您之前授予的刷新令牌的值 Google。以下是交换刷新令牌的请求示例 获取访问令牌:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

如需将刷新令牌交换为访问令牌,令牌交换端点 来响应 POST 请求:

  1. 验证 client_id 是否将请求来源标识为 Google,并 client_secret 与预期值一致。
  2. 请确认刷新令牌有效,以及在 请求与刷新令牌所关联的客户端 ID 相匹配。
  3. 如果您无法验证上述所有条件,则返回 HTTP 400 正文为 {"error": "invalid_grant"} 的 Bad Request 错误。
  4. 否则,请使用刷新令牌中的用户 ID 来生成访问权限 令牌。这些标记可以是任何字符串值,但它们必须是唯一的 代表用户和客户端,而不得 猜测。对于访问令牌,请记录令牌的到期时间, 通常在您发出令牌一小时后发送
  5. 在 HTTPS 的正文中返回以下 JSON 对象 回答:
    {
    "token_type": "不记名",
    "access_token": "ACCESS_TOKEN",
    “expires_in”:SECONDS_TO_EXPIRATION
    }
处理 userinfo 请求

userinfo 端点是受 OAuth 2.0 保护的资源,会返回关联用户的声明。实现和托管 userinfo 端点是可选的,但以下用例除外:

从您的令牌端点成功检索到访问令牌后,Google 会向您的 userinfo 端点发送请求,以检索关联用户的基本个人资料信息。

userinfo 端点请求标头
Authorization header Bearer 类型的访问令牌。

例如,如果您的 userinfo 端点可通过 https://myservice.example.com/userinfo 时,请求可能如下所示:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

为了让 userinfo 端点能够处理请求,请执行以下步骤:

  1. 从 Authorization 标头中提取访问令牌,并返回与访问令牌相关联的用户的信息。
  2. 如果访问令牌无效,则使用 WWW-Authenticate 响应标头返回 HTTP 401 Unauthorized 错误。下面是一个 userinfo 错误响应示例:
    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: error="invalid_token",
    error_description="The Access Token expired"
    
    如果在关联过程中返回 401 未经授权错误或任何其他失败的错误响应,该错误将无法恢复,检索到的令牌将被舍弃,并且用户必须重新开始关联流程。
  3. 如果访问令牌有效,则返回 HTTPS 正文中包含以下 JSON 对象的 HTTP 200 响应 回答:

    {
    "sub": "USER_UUID",
    "email": "EMAIL_ADDRESS",
    "given_name": "FIRST_NAME",
    "family_name": "LAST_NAME",
    "name": "FULL_NAME",
    "picture": "PROFILE_PICTURE",
    }
    如果您的 userinfo 端点返回 HTTP 200 成功响应,则系统会针对用户的 Google 账号注册检索到的令牌和声明。

    userinfo 端点响应
    sub 系统中用于识别用户的唯一 ID。
    email 用户的电子邮件地址。
    given_name 可选:用户的名字。
    family_name 可选:用户的姓氏。
    name 可选:用户的全名。
    picture 可选:用户的个人资料照片。

구현 확인

OAuth 2.0 플레이그라운드 도구를 사용하여 구현을 검증할 수 있습니다.

도구에서 다음 단계를 수행합니다.

  1. 구성 을 클릭하여 OAuth 2.0 구성 창을 엽니다.
  2. OAuth 흐름 입력란에서 클라이언트 측을 선택합니다.
  3. OAuth 엔드포인트 필드에서 맞춤을 선택합니다.
  4. 해당 필드에 OAuth 2.0 엔드포인트와 Google에 할당한 클라이언트 ID를 지정합니다.
  5. 1단계 섹션에서 Google 범위를 선택하지 않습니다. 대신 이 필드를 비워 두거나 서버에 유효한 범위 (또는 OAuth 범위를 사용하지 않는 경우 임의의 문자열)를 입력합니다. 완료되면 API 승인을 클릭합니다.
  6. 2단계3단계 섹션에서 OAuth 2.0 흐름을 진행하고 각 단계가 의도한 대로 작동하는지 확인합니다.

Google 계정 연결 데모 도구를 사용하여 구현을 확인할 수 있습니다.

도구에서 다음 단계를 수행합니다.

  1. Google 계정으로 로그인 버튼을 클릭합니다.
  2. 연결할 계정을 선택합니다.
  3. 서비스 ID를 입력합니다.
  4. 원하는 경우 액세스를 요청할 범위를 하나 이상 입력합니다.
  5. 데모 시작을 클릭합니다.
  6. 메시지가 표시되면 연결 요청에 동의하고 거부할 수 있음을 확인합니다.
  7. 플랫폼으로 리디렉션되는지 확인합니다.