대화형 작업이 2023년 6월 13일에 지원 중단되었습니다. 자세한 내용은
대화 작업 지원 중단을 참고하세요.
계정 연결 유형 선택 (Dialogflow)
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
작업에 가장 적합한 계정 연결 유형은 사용자에게 가장 간단한 환경을 제공하고 애플리케이션 또는 비즈니스의 요구사항에 맞는 유형입니다. 연결 유형을 선택할 때는 주로 다음 요소에 따라 달라집니다.
- 음성을 통한 계정 생성 허용 여부
- 사용자가 Google 이외의 계정으로 서비스에 로그인할 수 있도록 할지 여부
- 서비스에서 기밀 정보(예: 클라이언트 보안 비밀번호)를 저장할 수 있는지 여부
이상적인 계정 연결 유형을 알아보려면 다음 단계를 따르세요.
- 선호하는 로그인 유형 식별 섹션의 질문을 고려하세요.
- 결정 트리를 참고하여 연결 유형을 선택합니다.
- 선택한 초기 유형에 해당하는 섹션으로 이동하여 작동 방식을 더 세분화합니다.
원하는 로그인 유형 확인하기
결정 트리를 참고하기 전에 다음 질문을 고려하세요.
- 모든 사용자에게 Google 계정이 있어야 하나요?
- 작업이 어시스턴트만 타겟팅한다면 모든 사용자에게 Google 계정이 있을 것이라고 예상할 수 있습니다. 작업이 어시스턴트 이외의 플랫폼을 타겟팅하는 경우 모든 사용자에게 Google 계정이 있을 것이라고 예상할 수는 없습니다.
- 서비스에 이미 기존 사용자가 있다면 일부 사용자에게는 Google 계정이 없거나 Google 계정으로 서비스에 로그인하지 않았을 가능성이 높습니다.
- OAuth 구현이 있는 경우 Google 프로토콜을 지원하도록 확장할 수 있나요?
- Google 프로토콜을 지원하려면
intent=get 및 intent=create 기능을 토큰 교환 엔드포인트에 추가할 수 있어야 합니다. 이 기능을 사용하면 Google에서 사용자가 이미 백엔드에 있는지 확인하고 서비스에 각각 새 계정 생성을 요청할 수 있습니다.
아래의 결정 트리를 따라 나와 사용자에게 가장 적합한 계정 연결 유형을 찾아보세요.
연결 유형을 선택한 후 아래의 해당 섹션으로 진행하여 작동 방식을 자세히 알아보고 작업에서 계정 연결이 작동하는 방식에 관한 추가 결정을 내립니다.
OAuth 및 Google 로그인
OAuth 및 Google 로그인 (GSI) 연결 유형은 OAuth 기반 계정 연결 외에 GSI를 추가하므로 GSI의 이점 (예: Google 사용자를 위한 음성 기반 연결)을 제공하는 동시에 Google 이외의 계정으로 서비스에 등록한 사용자에게 계정 연결을 사용 설정할 수 있습니다. 이 연결 유형은 Google 사용자가 아닌 사용자를 위한 대체 과정을 원활하게 진행하므로 최종 사용자에게 특히 유용합니다. OAuth 및 GSI 연결 유형의 작동 방식에 관한 자세한 내용은 OAuth 및 Google 로그인 개념 가이드를 참고하세요.
OAuth 및 Google 로그인 연결 유형 조정
작업에서 OAuth 및 GSI 계정 연결 유형을 사용할 경우 Actions 콘솔에서 다음 질문에 대한 답변을 지정하여 작동 방식을 정의합니다.
음성 계정 생성을 사용 설정하시겠어요, 아니면 웹사이트에서 계정 생성만 허용하시겠어요?
일반적으로, 선택되지 않은 기기의 사용자가 다른 기기로 전송할 필요 없이 계정을 만들 수 있도록 음성을 통해 계정 생성을 사용 설정해야 합니다. 음성을 통한 계정 생성을 허용하지 않으면 어시스턴트가 사용자 인증을 위해 제공된 웹사이트 URL을 열고 사용자를 휴대전화로 안내하여 계정 연결 흐름을 계속 진행합니다.
하지만 다음 중 하나에 해당하는 경우 음성을 통한 계정 생성을 허용하면 안 됩니다.
- 계정 생성 흐름을 완전히 관리할 수 있어야 합니다. 예를 들어 계정 생성 또는 다른 유형의 고지 중에 사용자에게 서비스 약관을 표시해야 할 수 있습니다.
- 이미 계정이 있는 사용자가 해당 계정으로 로그인하도록 하려고 합니다. 예를 들어 포인트 제도를 제공하고 사용자가 계정에서 누적된 포인트를 잃지 않도록 하려면 사용자가 기존 계정을 계속 사용하도록 할 수 있습니다.
승인 코드 흐름을 사용하시겠습니까, 아니면 암시적 흐름을 사용하시겠습니까?
승인 코드 흐름과 암시적 흐름은 승인 코드 흐름에 두 번째 엔드포인트인 토큰 교환 엔드포인트가 필요하다는 점이 다릅니다. 이 엔드포인트는 갱신 토큰을 사용하여 사용자에게 다시 로그인하라는 메시지를 표시하지 않고 임시 액세스 토큰을 새로 생성합니다.
반대로 암시적 흐름을 사용하면 일반적으로 다시 생성할 필요가 없는 장기 액세스 토큰이 Google로 반환됩니다. 승인 코드 및 암시적 흐름에 대한 자세한 내용은 OAuth 및 Google 로그인 개념 가이드를 참조하세요.
작업의 승인 코드 흐름이 더 안전하기 때문에 Google은 이 과정을 사용하는 것이 좋습니다. 그러나 서비스가 기밀 정보 (즉, 클라이언트 보안 비밀번호)를 저장할 수 없는 경우 대신 암시적 흐름을 사용합니다.
예를 들어 단일 페이지 애플리케이션 (SPA)과 같은 공개 클라이언트의 암시적 흐름을 사용해야 합니다.
이러한 결정 지점을 고려한 후 다음 결정 트리를 참고하세요.
Google 로그인
GSI 연결 유형을 사용하면 작업이 대화 중에 사용자의 Google 프로필에 대한 액세스 권한을 요청하고 프로필 정보를 사용하여 사용자가 서비스의 백엔드에 있는지 확인할 수 있습니다. 사용자가 존재하지 않는 경우 Google 프로필 정보를 사용하여 시스템에서 새 계정을 만들 수 있습니다.
GSI의 경우 음성을 통한 계정 생성을 사용 설정해야 사용자가 음성으로 전체 흐름을 완료할 수 있습니다. GSI에 관한 자세한 내용은 Google 로그인 개념 가이드를 참고하세요.
OAuth
OAuth 연결 유형을 사용하면 사용자가 표준 OAuth 2 흐름으로 로그인합니다.
OAuth 연결 유형은 두 가지 업계 표준 OAuth 2.0 흐름, 즉 암시적 및 승인 코드 흐름을 지원합니다.
Google은 단독으로 OAuth 연결 유형을 사용하지 않는 것이 좋습니다. 사용자가 선택되지 않은 기기를 사용하는 경우 로그인 프로세스를 완료하기 위해 음성에서 화면으로 사용자를 이동해야 하기 때문입니다. OAuth 2 서버의 기존 구현이 있고 ID 토큰에서 자동 연결 및 계정 생성을 위한 Google 프로토콜 지원을 추가하기 위해 토큰 교환 엔드포인트를 확장할 수 없는 경우 이 흐름을 사용하는 것이 좋습니다. 자세한 내용은 OAuth 개념 가이드를 참고하세요.
흐름 다듬기
작업에서 OAuth 계정 연결 유형을 사용하는 경우 Actions 콘솔에서 다음 질문에 대한 답변을 지정하여 작동 방식을 정의해야 합니다.
승인 코드 흐름을 사용하시겠습니까, 아니면 암시적 흐름을 사용하시겠습니까?
OAuth 연결 유형은 두 가지 업계 표준 OAuth 2.0 흐름, 즉 암시적 및 승인 코드 흐름을 지원합니다. 승인 코드 흐름과 암시적 흐름은 승인 코드 흐름에 두 번째 엔드포인트인 토큰 교환 엔드포인트가 필요하다는 점에서 다릅니다. 이 엔드포인트는 사용자에게 다시 로그인하라는 메시지를 표시하지 않고 갱신 토큰을 사용하여 사용 기간이 짧은 새로운 액세스 토큰을 생성합니다.
반대로 암시적 흐름을 사용하면 일반적으로 다시 생성할 필요가 없는 장기 액세스 토큰이 Google로 반환됩니다. 승인 코드 및 암시적 흐름에 대한 자세한 내용은 OAuth 개념 가이드를 참조하세요.
작업의 승인 코드 흐름이 더 안전하기 때문에 Google은 이 과정을 사용하는 것이 좋습니다. 그러나 서비스가 기밀 정보 (즉, 클라이언트 보안 비밀번호)를 저장할 수 없는 경우 대신 암시적 흐름을 사용합니다.
예를 들어 단일 페이지 애플리케이션 (SPA)과 같은 공개 클라이언트의 암시적 흐름을 사용해야 합니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-07-26(UTC)
[null,null,["최종 업데이트: 2025-07-26(UTC)"],[[["\u003cp\u003eThis guide helps you choose the best account linking type for your Google Action based on factors like user experience and security needs.\u003c/p\u003e\n"],["\u003cp\u003eThree main linking types are discussed: OAuth and Google Sign-In (recommended), Google Sign-In, and OAuth.\u003c/p\u003e\n"],["\u003cp\u003eEach type has different features and considerations, such as whether to allow voice account creation or use authorization code versus implicit flow.\u003c/p\u003e\n"],["\u003cp\u003eDecision trees and further details are provided to refine your chosen linking type for optimal implementation within your Action.\u003c/p\u003e\n"],["\u003cp\u003eOAuth and Google Sign-In offer a combined approach for both Google and non-Google user accounts, providing a smoother experience.\u003c/p\u003e\n"]]],[],null,["# Choose your account linking type (Dialogflow)\n\nThe optimal account linking type for your Action is one that provides the\nsimplest experience for your users and fits the needs of your application or\nbusiness. Choosing your linking type is mostly dependent on the following\nfactors:\n\n- Whether you want to allow account creation via voice\n- Whether you want users to be able to sign in to your service with a non-Google account\n- Whether or not your service can store confidential information (i.e., a client secret)\n\nTo figure out your ideal account linking type, follow these steps:\n\n1. Consider the questions in the [Identify your preferred sign-in type](#identify_your_preferred_sign-in_type) section.\n2. Consult the decision tree to choose your linking type.\n3. Navigate to the section that corresponds to the initial type you chose to further refine how it works.\n\nIdentify your preferred sign-in type\n------------------------------------\n\nBefore you consult the decision tree, consider the following questions:\n\n- **Do you expect all your users to have a Google account?**\n - If your Action only targets the Assistant, then you can expect all your users to have a Google account. If your Action targets platforms beyond the Assistant, you cannot expect all your users to have a Google account.\n - If your service already has existing users, it's likely that some don't have a Google account or didn't sign into your service with a Google account.\n- **If you have an OAuth implementation, can it be extended to support Google\n protocol?**\n - To support Google protocol, you need to be able to add the `intent=get` and `intent=create` functionality to your token exchange endpoint. This functionality allows Google to check if the user already exists in your backend and make a request to create a new account on your service, respectively.\n\nFollow the decision tree below to identify the account linking type that's\noptimal for you and your users:\n\nOnce you select a linking type, continue to the corresponding section\nbelow to learn more about how it works and make further decisions about how\naccount linking works in your Action.\n\n### OAuth and Google Sign-In\n\nThe OAuth and Google Sign-In (GSI) linking type adds GSI on top of OAuth-based\naccount linking, which provides the benefits of GSI (for example, voice-based\nlinking for Google users) while also enabling account linking for users who\nregistered to your service with a non-Google account. This linking type is\nespecially advantageous for end users because it provides a low-friction flow\nfor Google users with a fallback for non-Google users. For more information\nabout how the OAuth and GSI linking type works, see the\n[OAuth and Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-oauth-concept-guide).\n\n#### Refine the OAuth and Google Sign-In linking type\n\nWhen you use the OAuth and GSI account linking type in your Action, you specify\nthe answers to the following questions in the Actions console to define how\nit works:\n\n1. **Do you want to enable voice account creation or only allow account\n creation on your website?**\n\n Generally, you should enable account creation via voice so that\n users on a non-screened device can create an account without having to\n transfer to another device. If you do not allow account creation via voice, the\n Assistant opens the URL to the web site that you provided for user\n authentication and directs the user to a phone to continue the account\n linking flow.\n\n However, you should not allow account creation via voice if any of the\n following applies:\n 1. *You need full control of the account creation flow.* For example, you may need to show your terms of service to the user during account creation or some other type of notice.\n 2. *You want to ensure that users who already have an account with you\n sign in with that account.* For example, you may want users to continue using their existing accounts if you offer a loyalty program and don't want the user to lose the points accrued on their account.\n2. **Do you want to use the authorization code flow or implicit flow?**\n\n The authorization code flow and implicit flow differ in that the\n authorization code flow requires a second endpoint, the *token exchange*\n endpoint. This endpoint uses *refresh tokens* to generate new, short-lived\n access tokens without prompting the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth and Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs).\n\nAfter considering these decision points, consult the following decision tree:\n\n### Google Sign-In\n\nWith the GSI linking type, your Action can request access to your user's Google\nprofile during a conversation and use the profile information to check if the\nuser exists in your service's backend. If the user doesn't exist, they can\ncreate a new account in your system using their Google profile information.\n\nFor GSI, you must enable account creation via voice, which lets the user\ncomplete the entire flow over voice. For more information about GSI, see the\n[Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-concept-guide).\n\n### OAuth\n\nWith the OAuth linking type, the user signs in with the standard OAuth 2 flow.\nThe OAuth linking type supports two industry-standard OAuth 2.0 flows:\nthe *implicit* and *authorization* code flows.\n\nGoogle does not recommend the OAuth linking type by itself because it requires transferring\nthe user from voice to screen to complete the sign-in process if the user is on\na non-screened device. You can consider using this flow if you have an existing\nimplementation of an OAuth 2 server, and you cannot extend the token exchange\nendpoint to add support for Google's protocols for automatic linking and\naccount creation from an ID token. For more information, see the\n[OAuth concept guide](/assistant/df-asdk/identity/oauth-concept-guide).\n\n#### Refine the flow\n\nWhen you use the OAuth account linking type in your Action, you must\nspecify the answer to the following question in the Actions console to define\nhow it works:\n\n1. **Do you want to use the authorization code flow or implicit flow?**\n\n The OAuth linking type supports two industry-standard OAuth 2.0 flows:\n the *implicit* and *authorization* code flows. The authorization code flow\n and implicit flow differ in that the authorization code flow requires a\n second endpoint, the *token exchange* endpoint. This endpoint uses\n *refresh tokens* to generate new, short-lived access tokens without prompting\n the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth concept guide](/assistant/df-asdk/identity/oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs)."]]
