OCPP2.0.1, Security - 1.3.7 TLS with Client Side Certificates - Requirements (번역)

OCPP 2.0.1 Secure lv3. Requirements 

p.s. CSMS(서버) - CS(클라이언트) 로 해석하면 일반적인 경우로 확대 해석 가능.

1. 충전소(CS : Charging Station, client)는 CS 인증서로 CSMS(Charging Station Management System, server)에 자신을 인증해야 합니다.

2. CS 인증서는 TLS(전송 계층 보안 : Transport Layer Security) client 측 인증서로 사용되어야 합니다.

3. CSMS는 아래 RFC5280 문서의 6절에 설정된 경로 검증 규칙에 따라 충전소 인증서의 인증 경로를 검증해야 합니다. 

인터넷 X.509 공개 키 기반 구조 인증서 및 CRL(인증서 해지 목록) 프로필 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Internet Engineering Task Force, Request for Comments 5280, May 2008, http://www.ietf.org/rfc/rfc5280.txt

4. CSMS는 인증서의 subject 필드에 있는 O(organizationName) RDN(Relative Distinguished Name : 상대 고유 식별명)에, CSO(Charging Station Operator : 충전소 운영자) 이름이 포함되어 있는지 확인하여, 인증서가 CSO(또는 CSO가 신뢰하는 조직)의 소유인지 확인해야 합니다.

5. CSMS는 인증서의 subject 필드에 있는 CN(commonName) RDN에, 충전소 고유 serial-number 가 포함되어 있는지 확인하여, 인증서가 이 충전소용인지 확인해야 합니다(인증서 속성 참조).

6. CSO가 충전소 인증서를 소유하지 않은 경우(예: 설치 직후)엔, 충전 스테이션과 계속 통신하기 전에 인증서를 업데이트하는 것이 좋습니다(설치 참조).

7. 충전소에 유효한 인증서가 없거나 인증 경로가 잘못된 경우, CSMS는 연결을 종료해야 합니다.

8. 7번이 발생하면, CSMS에 보안 이벤트를 기록하는 것이 좋습니다.

9. CSMS는 TLS 서버로 작동해야 합니다(SHALL).

10. CSMS는 CSMS 인증서를 서버 측 인증서로 사용하여 자신을 인증해야 합니다.

11. 충전소는 RFC5280 문서의 6절에 설정된 경로 유효성 검사 규칙에 따라 CSMS 인증서의 인증 경로를 확인해야 합니다.

12. 충전소는 commonName이 CSMS의 FQDN(Fully Qualified Domain Name : 도메인명) 과 일치하는지 확인해야 합니다.

13. CSMS가 유효한 인증서를 소유하지 않거나 인증 경로가 잘못된 경우, 충전소는 InvalidCsmsCertificate 보안 이벤트를 트리거해야 합니다(보안 이벤트의 전체 목록은 2부 부록 참조).

14. 13번이 발생하면, 충전소는 연결을 종료해야 합니다.

15. 통신 채널은 TLS를 사용하여 보호되어야 합니다(SHALL).

16. 충전소 및 CSMS는 TLS v1.2 이상만 사용합니다(SHALL).

17. 양 끝단 모두, 사용된 TLS 버전을 확인 해야 합니다.(SHALL)

18. 17에서 CSMS는, 충전소가 이전 버전의 TLS용 연결만 허용하거나, SSL만 허용함을 감지하면, CSMS는 연결을 종료해야 합니다.

19. 17에서 충전소는, CSMS가 이전 버전의 TLS용 연결만 허용하거나, SSL만 허용함을 감지하면, 충전소는 InvalidTLSVersion 보안 이벤트를 트리거하고 연결을 종료해야 합니다(보안 이벤트의 전체 목록은 2부 부록 참조).

20. TLS는 수정 없이, 위의 TLS Protocol 또는 그 후속 표준과 같이 구현되어야 합니다(SHALL).

The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force, Request for Comments 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt

21. CSMS는 최소 아래의 cipher suit를 지원해야 합니다.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256 

TLS_RSA_WITH_AES_256_GCM_SHA384

참고: CSMS는 두 암호 제품군을 모두 지원하기 위해 2개의 다른 인증서를 제공해야 합니다. 또한 보안 프로필 3을 사용할 때 CSMS는 두 암호 제품군에 대한 클라이언트 측 인증서를 생성할 수 있어야 합니다.

22. 충전소는 아래중 한줄의 cipher suit를 지원해야 합니다.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 와 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256 와 TLS_RSA_WITH_AES_256_GCM_SHA384

참고 1: TLS_RSA는 순방향 보안을 지원하지 않으므로 TLS_ECDHE가 권장됩니다. 또한 충전소가 안전하지 않은 알고리즘 사용을 감지하면 InvalidTLSCipherSuite 보안 이벤트를 트리거해야 합니다(SHOULD)(보안 이벤트의 전체 목록은 2부 부록 참조).

참고 2: ISO15118-2는 EV와 충전 사이의 통신을 위해 다음 암호 제품군을 구현하도록 규정하고 있습니다.

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

23.  충전소와 CSMS는 아래 문서(ENISA Algorithms report)에서, 레거시 사용에 적합하지 않은 것으로 표시된, 암호화 기본 형식을 사용하는 암호 제품군을 사용하지 않아야 합니다. 이것은 이 사양에 설명된 하나(또는 그 이상)의 암호 제품군이, 레거시 사용에 부적합한 것으로 표시되면 더 이상 사용하지 않아야 함을 의미합니다.

ENISA European Network and Information Security Agency, Algorithms, key size and parameters report 2014, 2014. (last accessed on 17 January 2016) https://www.enisa.europa.eu/publications/algorithms-key-size-and-parametersreport-2014

24.  TLS 서버 및 클라이언트는 아래 RFC3749의 섹션 6에 설명된 대로 압축 side-channel 공격을 피하고 상호 운용성을 보장하기 위해, TLS 압축 방법을 사용하지 않아야 합니다.

Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004. https://www.ietf.org/rfc/rfc3749.txt 

25. 24번에서 CSMS가 충전소가 이러한 제품군 중 하나를 사용하는 연결만 허용한다는 것을 감지하는 경우, CSMS는 연결을 종료해야 합니다.

26. 24번에서 충전소는 CSMS가 이러한 제품군 중 하나를 사용하는 연결만 허용함을 감지하는 경우, 충전소는 InvalidTLSCipherSuite 보안 이벤트를 트리거하고 연결을 종료해야 합니다(보안 이벤트의 전체 목록은 2부 부록 참조).

27. 각 충전소에 대해 고유한 충전소 인증서를 사용해야 합니다(SHALL).

28. 충전소 인증서는 충전소와 전기 자동차 간의 TLS 연결을 설정하는 데 사용되는 ISO15118-2의 SECC 인증서와 동일한 인증서일 수 있습니다(MAY).

[ISO15118-2] Road vehicles – Vehicle to grid communication interface – Part 2: Technical protocol description and Open Systems Interconnection (OSI) layer requirements, Document Identifier: 69/216/CDV. https://webstore.iec.ch/publication/9273 

원본 출처 : OCA OCPP 2.0.1 part2 Specification (2020-03-31)

Python OCPP 패키지 - Server 소스 해설

파이썬용 OCPP 패키지 서버 해설 - 원문 링크

 OCPP(Open Charge Point Protocol)은 두가지 역할 이 있다 - 중앙 서버(서버) 와 충전포인트(클라이언트). OCPP Python 패키지는 양쪽 연결을 모델링하는데 사용 가능하다.

이 문서는 중앙서버를 만드는 방법과 서버측에서 충전포인트를 모델링하는방법을 설명한다.  이 페이지 대부분의 예제는 websockets 계층 구현을위하여 websockets 라이브러리를 사용한다. 꼭 이걸 사용하지 않고, 다른 웹소켓을 적용해도 동작은 잘 될것이다.

Create a websocket server

아래 아주 간단한 예제는 접속 포트 9000을 사용하는 웹소켓 서버이고, 새로운 모든 웹소켓 연결에 대해 'Charge point connected' 를 인쇄한다.

import asyncio
import websockets


async def on_connect(websocket, path):
   await websocket.send('Connection made succesfully.')
   print(f'Charge point {path} connected')


async def main():
   server = await websockets.serve(
      on_connect,
      '0.0.0.0',
      9000,
      subprotocols=['ocpp1.6']
   )

   await server.wait_closed()


if __name__ == '__main__':
   asyncio.run(main())

설명이 필요한 두가지가 있다.

  ㅇ on_connect()에 첫번째 인자로 websockets.server() 의 핸들러가 전달된다. 이 핸들러는 모든 새 연결에서 실행된다.

핸들러는 2개의 인자를 전달 하는데, websockets.server.WebSocketServerProtocol과 요청 URI 이다.  요청 URI는 연결을 요청한 충전포인트의 식별자로 사용된다. 아래에 OCCP-J 사양의 3.1.1절을 인용한다.

  "충전포인트의 연결 URI는 충전점의 식별자가 포함되어, 중앙 서버가 어떤 충전점에 해당 websocket이 속해있는지 알게 한다."

  이 예제의 핸들러는 클라이언트에 메시지를 보내고 콘솔에 메시지를 출력한다.

  ㅇ websockets.server()의 subprotocol 인자는 OCPP 1.6을 지원하는 서버를 구성하는데 사용된다.

서버를 시작한 후, 웹소켓 대화형 클라이언트를 사용하여 클라이언트를 서버에 연결할 수 있다.

$ python -m websockets ws://localhost:9000/test_charge_point
Connected to ws://localhost:9000/test_charge_point.
< Connection made successfully.
Connection closed: code = 1000 (OK), no reason.

OCPP compliant handler 

(OCPP 준수(규정을 따르는) 핸들러)

위의 웹소켓 서버 예제는 OCPP 규정을 따르지 않기 때문에, 그닥 좋지 않다.

위의 코드에서 on_connect() 핸들러를 제거하고 다음 예제대로 바꾼다.

from datetime import datetime

from ocpp.routing import on
from ocpp.v16 import ChargePoint as cp
from ocpp.v16.enums import Action, RegistrationStatus
from ocpp.v16 import call_result


class MyChargePoint(cp):
    @on(Action.BootNotification)
    def on_boot_notitication(self, charge_point_vendor, charge_point_model, **kwargs):
        return call_result.BootNotificationPayload(
            current_time=datetime.utcnow().isoformat(),
            interval=10,
            status=RegistrationStatus.accepted
        )


async def on_connect(websocket, path):
    """ For every new charge point that connects, create a ChargePoint instance
    and start listening for messages.

    """
    charge_point_id = path.strip('/')
    cp = MyChargePoint(charge_point_id, websocket)

    await cp.start()

on_connect() 핸들러가 갱신되면, 이제 MyChargePoint 인스턴스를 생성하고 start() 코(부속)루틴을 호출한다. 

MyChargePoint는 ocpp.v16.ChargePoint의 Subclass 이다. ocpp.v16.ChargePoint는 OCPP 패키지의 핵심이다.  이 클래스는 클라이언트에서 올라오는 메시지를 올바른 핸들러(처리기)에 할당한다.  또한, 송/수신중인 모든 메시지의 유효성을 검사하고 흐름제어를 구현한다.

MyChargePoint 클래스는 'BootNotification' 요청 구현을 위해서 @On() 데코레이터를 사용한다. @On() 은 단일 인자로 문자열로된 액션의 이름을 사용한다.  비록 이 예제에서는 사용하지 않았지만, ocpp 패키지는 후처리 요청 핸들러로 사용 가능한 @after() 데코레이터도 제공한다. 

OCPP 스펙(사양)에 따르면, BootNotification 요청의 내용(페이로드)에 반드시 필요한 2가지는 'chargePointModel' 과 'chargePointVendor' 이고, 부가적으로 7가지의 옵션 인자가 있다.  핸들러(처리기)는 두개의 필수인자 charge_point_vendor 와 charge_point_model을 사용해서 이를 적용한다.  핸들러는 옵션 인자로 **kwargs 를 사용한다.

핸들러(처리기)는 ocpp.v16.call_result.BootNotificationPayload의 인스턴스를 반환한다.  이 객체는 클라이언트로 돌려보내는 응답을 만들 때 사용한다.

노트:

OCPP는 페이로드 키값에 낙타형 명명방식을 사용하는데, 파이썬은 snake_case 방식을 사용한다.  그러므로, 이 ocpp 패키지는 메시지의 모든 키를 낙타형에서 snake_case 로 또는 그 반대로 변환하여 파이썬 코드를 작성하도록 유의하라.

이제 websocket 서버를 다시 시작하고, 이전과 같이 클라이언트를 연결한다. 클라이언트가 연결되면, BootNotification을 중앙시스템(서버)로 전송한다.

`[2, "12345", "BootNotification", {"chargePointVendor": "The Mobility House", "chargePointModel": "Optimus"}]`

서버가 응답하고, 아래와 같이 표시되어야 한다.

$ python -m websockets ws://localhost:9000/test_charge_point
Connected to ws://localhost:9000/test_charge_point.
> [2, "12345", "BootNotification", {"chargePointVendor": "The Mobility House", "chargePointModel": "Optimus"}]
< [3, "12345", {"currentTime": "2019-06-16T11:18:09.591716", "interval": 10, "status": "Accepted"}]`

축하!!. 중앙시스템(서버)를 만들었다.

이 문서에서 만든 서버 소스코드는 examples 디렉토리에서 찾을 수 있다.

[번역] Fulfillment and authentication - Google Assistant - Action on Google

Fulfillment and authentication (이행 과 인증)

Fulfillment (이행, 수행)

Fulfillment는, smart home intent 에 대해 동적으로 응답을 생성할 수 있는, 웹 후크로 배포되는 코드이다. Google Assistant와 사용자 conversation 동안, fullfillment는 Google의 자연어 처리 프로세스에서 추출한 정보를 사용하여, 백엔드에서 조명켜기와 같은 동적 응답을 생성하거나, 조치를 트리거(시작)할 수 있다.

Fulfillment는 Assistant의 요청을 수신하고, 요청을 처리하고 응답한다.  이 back and-forth 요청과 응답 프로세스는 결국 초기 사용자 요구를 fulfill(이행)할 때까지, conversation을 할 수 있도록 이끈다. 대부분의 경우, 사용자는 'Hay Google, turn on my light.' 처럼 단순 Google Assistant와 단순 스마트홈 interaction(상호작용)한다.  하지만, two-factor authentication을 구현해야한다면, fulfillment는 'Hay Google, unlock my front door.'와 같은 Google Assistant에게 특수 요청 이후, PIN 인증을 요청하는것 처럼, 다중 요청과 응답을 처리해야할 수도 있다.

그림1은 스마트홈 EXECUTE intent의 정상적인 fulfillment와 execution을 보여준다.

Authentication (인증, 입증)

Authentication을 통해서, 사용자의 Google 계정을 인증 시스템의 사용자 계정과 연결할 수 있다. 이것은 fulfillment 위에 스마트홈 intent를 수신하면. 사용자 식별이 가능하도록 한다.  Google smart home은 authorization code flow의 OAuth만 지원한다.

Smart home의 경우, authorization 과 token exchange endpoint 두개의 endpoint가 필요한 authorization code flow의 OAuth를 사용해야한다. account linking with OAuth 참조

사용자를 인증하면, 스마트홈 intent가 fulfillment를 전송할 때, Authorization header에 사용자의 타사 OAuth2 access token이 전송된다.  모든 사용자는 장치정보가 Assistant에게 action.devices.SYNC intent와 함께 전송되기 때문에, account linking을 수행 해야만한다.

스마트홈 Action은 동일한 사용자 계정에 연결하는 여러 Google 사용자를 지원할것으로 예상된다(예: 사용자가 집안의 다른 사용자에게 액세스 권한을 부여할 때). 서비스에서 여러 사용자 연결을 지원할 수 없는 경우, 계정 연결 시, 오류가 발생해야한다.

[번역]Account linking with Google Sign-In - Google Assistant - Action on Google

Google Sign-In 으로 계정 연결하기

원문그대로 번역했으나, 화면이 현재 화면과 다름. 내용만 참조할 것.

Assistant 의 Google Sign-in은 사용자와 개발자 모두에게 Account linking 과 Account creation하기 가장 단순하고 쉬운 사용자환경을 제공한다. Action은 conversation 동안, 사용자명, 이메일, 프로필사진 등의 사용자의 구글 프로필정보 에 접근을 요청할 수 있다.
프로필 정보는 Action에서 개인화된 user experience 를 만드는데 사용될 수 있다.  만약, 다른 플랫폼용 앱이 있고, Google Sigh-In을 사용하면, 그 시스템에 기존 사용자 계정을 찾아 연결 가능하고, 새 계정 생성 또는 직접 communication 채널을 만드는것도 가능해진다.
Google Sign-In 으로 Account linking을 수행하기 위해선, 사용자에게 Google 프로필 접근 허용 동의를 요청한다.그런 다음, 시스템에서 사용자를 식별하여 프로필 정보(예:이메일 주소)를 사용한다.

Google Sign-In account linking 구현

아래 섹션의 단계에 따라 Action에 Google Sign-In account linking을 추가한다.

note : 금융 관련 계정 연결은 작업 검토에 6주 소요되므로, 릴리즈 계획에 시간 고려 필요.금융 서비스 정책 참조

프로젝트 설정

Google Sign-In account linking 을 사용하도록 프로젝트를 설정하려면, 아래 단계를 따름.

1. Action Console을 열고 프로젝트를 선택
2. Develop 탭을 클릭해서, Account Linking을 선택
3. Account Creation에서 'Yes, allow users to sign up for new accounts via voice' 선택
4. Linking type에서 'Google Sign In' 을 선택
5. Client Information을 열고, Client ID issued by Google to your Actions 항목 값을 메모
6. Save 클릭

인증 flow 시작

주의 : Action의 conversation 시작 시, 계정 연결 요청하지 말것.  대신에, 인증되지 않은 사용자에게 게스트 flow를 제공하여, Action의 작동 방식을 보여준 후에, 진행이 필요한경우에만 Account linking 을 요청할것.  계정문제때문에 사용자가 떠나는 경우가 지속적으로 발생하게되면, 구글은 Action을 적극적으로 홍보하지 않기 때문에, Action 사용자 트래픽이 감소하게됨.

인증된 사용자만 Account linking을 수행할 수 있음. Guest의 경우, account linking은 실패함.  게스트 사용자 처리와 인증에 관한 내용 살펴볼것.

인증 flow를 시작하려면, Account Sign-in helper intent 를 사용함.

사용자가 Action이 Google 프로필에 접근할 수 있는 권한 부여 후, 액션에 대한 모든 후속요청에, 사용자의 Google 프로필 정보가 포함된 Google ID 토큰을 받게 된다.

사용자의 프로필 정보에 접근하려면, 먼저, 다음을 수행하여 토큰의 유효성점검과 디코드를 수행한다.

1. 해당 언어에 맞는 JWT-decoding library 를 사용하여 토큰을 해독하고, Google의 공개키(JWK or PEM 형식으로 제공)를 사용하여 토큰의 서명을 확인한다.
2. 토큰의 발행자(decoded token에 iis 필드)가 https://accounts.google.com 이고,  audience (decoded token에 aud  필드)가 Action on Google consol의 해당 프로젝트에서 발행된 Client ID issued by Google to your Actions 값인지 확인하라. 

샘플 코드는 상단 원본 링크에서 확인..

Actions on Google client library for Node.js 또는 the Java client library를 사용한다면, 프로파일 컨텐츠에 접근 권한 부여 등의 작업에서, 할당된 토큰을 디코드 또는 유효성 검증에 주의 해야한다. 아래 code snippets(코드 요약 예) 가 있다. 아래 JSON은 각각 Dialogflow와 Actions SDK의 webhook 요청을 설명한다.

다음 스니펫은 로그인에 Dialogflow을 사용한다.
샘플 코드는 상단 원본 링크에서 확인..

다음 스니펫은 로그인에 Actions SDK를 사용한다.
샘플 코드는 상단 원본 링크에서 확인..

Handle data access requests (데이터 접근 요청 처리)

데이터 접근 요청을 처리하려면 Google ID 토큰이 제시한 사용자가 DB에 먼저 등록되어있어야 한다. 아래 스니펫은 사용자 계정이 이미 Firestore 데이터베이스에 있는지 확인하는 방법 예시임.
샘플 코드는 상단 원본 링크에서 확인..

[번역]Account linking with OAuth [Implicit flow]- developers.google.com

[원문] - 원문과 같으나, 현재 설정 화면은 다름

OAuth 로 Account linking 하기

OAuth linking type은 2개의 산업표준 [ implicit 와 authorization 코드 플로우] 가 있다

implicit code flow는 구글이 authorization endpoint를, 브라우저 안에서 열고, 로그인 성공한 후, long-lived access token 을 구글에 반환한다. 이 access token은 Assistant 에서 your Action 으로 보내는 모든 request 에 포함된다.

authorization code flow는 두개의 endpoint가 필요하다.
 ㅇ The authorization endpoint :  아직 로그인 하지 않은 사용자에게 로그인 UI를 제공하고, short-lived authorization code 형식으로 접근 요청을 동의 하고, 기록한다.
ㅇ The token exchange endpoint : 두가지 타입의 교환 역할을 담당한다.
  1. a long-lived refresh token 과 a short-lived access token의 인증 코드를 교환
  2. a short-lived access token을 a long-lived refresh token 으로 교체. 이 교환은 구글이 만료된 새 access token이 필요할 때 발생한다.

비록 the implicit code flow는 적용하기 간단하지만, 구글은 만료기간 없는 the implicit flow 를 access tokens 로 사용하길 권장한다. 토큰 만료된 the implicit flow 는 사양자를 다시 계정에 링크하도록 강요하기 때문이다. 만약, 보안등의 문제로 토큰 만료가 필요한 경우엔, 대신, the auth code flow 를 사용할것을 강력히 고려하라.

[ Implicit flow ] ======================

Implement OAuth account linking

ㅇ 금융 관련 계정 연결은 작업 검토에 6주 소요되므로, 릴리즈 계획에 시간 고려 필요.
금융 서비스 정책 참조

프로젝트 구성
OAuth 계정 연결을 사용하도록 프로젝트를 구성하려면 다음 단계를 수행할 것.

1. the Actions Console 을 열고 사용하려는 프로젝트를 선택.
2. Develop 탭을 클릭하고 Account linking을 선택 .
3. Account creation 에서 No, I only want to allow account creation on my website. 선택 
   
4. Linking type 에서 OAuth and Implicit 선택.
   
5. Client Information 에서  

        ㅇ 구글에서 오는 요청 식별에 Client ID issued by your Actions to Google 로 설정

        ㅇ Authorization 과 Token Exchange endpoint 의 URL을 입력

• 참고 : 클라이언트 ID를 base64로 인코딩된 문자열로 보내려면, Configure your client (optional) 옆에있는 콤보박스에서 Google to transmit clientID and secret via HTTP basic auth header 에 체크함. 

    6. Save 클릭

OAuth 서버 구현

the OAuth 2.0 implicit flow를 지원하려면,  authorization endpoint가 HTTPS를 사용하도록 

서비스를 만들어야 한다. 이 endpoint 는 데이터 액세스에 대한 사용자의 인증 및 동의역할을 한다.  The authorization endpoint는 아직 로그인을 하지 않은 사용자에게 로그인 UI를 제공하고, 요청된 액세스에대한 동의를 기록한다.

액션이 인증관련 API를 호출해야 한다면, 구글은 이 엔드포인트를 사용하여, 사용자로부터 사용자를 대신해, 해당 API를 호출할 수 있는 권한을 얻는다.

일반적인 OAuth 2.0 implicit flow session은 다음과 같은 흐름을 갖는다.

1. Google은 사용자의 브라우저에서 authorization endpoint 를 연다. 사용자는 아직 로그인하지 않은 경우 로그인하고, 아직 권한을 부여하지 않은 경우, API를 사용하여 데이터에 액세스 할 수있는 권한을 Google에 부여한다.
2. 서비스는 access token을 생성 하고 요청에 첨부 된 access token을 사용하여 사용자의 브라우저를 다시 Google로 리디렉션하여 access token을 Google에 반환한다.
3. Google은 서비스 API를 호출하고 각 요청마다 access token을 첨부합니다. 서비스는 access token이 Google에 API 접근 권한을 부여했는지 확인한 다음, API 호출을 완료한다.

승인 요청 처리

액션이 OAuth2 implicit flow를 통해서 계정 연결을 수행해야하는 경우, Google은 아래 매개변수가 포함 된 요청으로 사용자를 권한부여 엔드포인트로 보낸다.

권한 엔드 포인트 매개 변수
client_id	Google에 할당 한 고객 ID
redirect_uri	이 요청에 대한 응답을 보내는 URL입니다.
state	리디렉션 URI에서 변경되지 않은 채 Google에 다시 전달되는 부기 값입니다.
response_type	응답에 반환 할 값의 유형입니다. OAuth 2.0 암시 적 플로우의 경우 응답 유형은 항상 token입니다.

예를들어, authorization endpoint가 https://myservice.example.com/auth 라면, 요청 명령은

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token

위와 같을것이다.

authorization endpoint 가 로그인 요청을 처리하려면, 다음 단계를 수행한다.

1. 의도하지 않거나 잘못 구성된 클라이언트 앱에 대한 액세스 권한을 부여하지 않으 려면 client_id및 redirect_uri값을 확인.
   • client_idGoogle에 할당 한 고객 ID와 일치 하는지 확인 .
   • redirect_uri 매개 변수로 지정된 URL의 형식이 다음과 같은지 확인.

     https://oauth-redirect.googleusercontent.com/r/ YOUR_PROJECT_ID

     YOUR_PROJECT_ID 는 작업 콘솔 의 프로젝트 설정 페이지 에있는 ID.
2. 사용자가 서비스에 로그인했는지 확인. 사용자가 로그인하지 않은 경우, 서비스의 로그인 또는 가입 절차를 완료.
3. Google이 API에 액세스하는 데 사용할 access token을 생성. access token은 임의의 문자열 값일 수 있지만, 토큰은, 사용자와 클라이언트를 고유하게 나타내야하며 추측 할 수 없어야함.
4. 사용자의 브라우저에서 redirect_uri매개 변수로 지정된 URL로 redirect하는 HTTP response 을 전송 . URL fragment에 다음 parameters를 모두 포함.
• access_token: 방금 생성 한 액세스 토큰
• token_type: 문자열 bearer
• state: 원래 요청의 수정되지 않은 상태 값. 다음은 결과 URL의 예.

https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING

Google의 OAuth 2.0 redirect handler는 access token을 받고, state 값이 변하지 않다는걸 확인. Google이 Service에 대한 access token을 획득한 후, Google은 이후, AppRequest의 일부인, 액션 명령에 토큰을 첨부한다.

Start the authentication flow

경고 : Action의 대화작업을 시작할 때, 사용자에게 필요한 account linking prompt를 제공하지 말것. 대신, 인증되지 않은 사용자에게 게스트 flow를 제공하여, 작업의 작동 방식을 보여준 다음, 진행이 필요한 경우에만 계정 연결을 요청. 계정 연결 문제로 인해 사용자가 액션을 떠나도, Google은 액션을 적극적으로 홍보하지 않으므로, Action의 사용자 트래픽이 줄어들 수 있다.

Account Sign-in helper intent 를 사용해 the authentication flow를 시작한다.  아래 코드 스니펫은, 이 helper를 사용하기위한, Dialogflow 및 Actions SDK에서 응답을 보내는 방법을 기술한다.

Dialogflow:

const {dialogflow, SignIn} = require('actions-on-google');
const app = dialogflow({
  // REPLACE THE PLACEHOLDER WITH THE CLIENT_ID OF YOUR ACTIONS PROJECT
  clientId: CLIENT_ID,
});
// Intent that starts the account linking flow.
app.intent('Start Signin', (conv) => {
  conv.ask(new SignIn('To get your account details'));
});

Actions SDK:

const {actionssdk, SignIn} = require('actions-on-google');
const app = actionssdk({
  // REPLACE THE PLACEHOLDER WITH THE CLIENT_ID OF YOUR ACTIONS PROJECT
  clientId: CLIENT_ID,
});
// Intent that starts the account linking flow.
app.intent('actions.intent.TEXT', (conv) => {
  conv.ask(new SignIn('To get your account details'));
});

Handle data access requests

만약, Assistant request가 access token을 포함한다면, 우선 access token이 유효한가(만료되었나) 검사를 하고, DB에서 후속 사용자 계정을 검색 할 것.