인증서 설치 - OCPP 2.0.1 문서 번역

 인증서 설치

HTTP 기본 인증(충전소 인증 참조)에 사용되는 비밀번호이든 CS 인증서이든, 각 CS를 CSMS에 인증하려면 고유한 자격 증명을 사용해야 합니다. 이러한 고유 자격 증명은 제조 또는 설치 중 어느 시점에서 충전 스테이션에 넣어야 합니다.

인증서 설치 요구사항

1. (권장)제조업체는 (충전기를)만들 때, 고유한 자격 증명(unique credentials)으로 충전소를 초기화(initialize)하는 것이 좋습니다.

2. 자격 증명은 암호화 난수 생성기(cryptographic random number generator)를 사용하여 생성하고, 안전한 환경에 설치해야 합니다(SHOULD).

3. (인증서는) CSO가 CSMS에서 요청할 때, 보안 채널을 통해 CSO로 보내져야 합니다(SHOULD). They SHOULD be sent to the CSO over a secure channel, so that the CSO can import them in the CSMS

4. 제조업체는 자체 인증서를 사용하여 서명할 수 있습니다(MAY).

5. 설치 후, CSO는 아래 두개의 섹션에서 설명된 방법을 사용하여, 자격 증명을 즉시 업데이트()할 것을 권장합니다.

A01 - HTTP 기본 인증을 위한 충전소 비밀번호 업데이트 

A02 - CSMS 요청에 따라 충전소 인증서 업데이트 

6. CSMS는 충전소가 사용할 수 있는 기능을 제한할 수 있습니다. CSMS는 BootNotification 상태인 Pending을 사용할 수 있습니다. 보류 중 상태에서 CSMS는 자격 증명을 업데이트할 수 있습니다.

Certificate Properties (인증서 속성)

인증서 속성 정리

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

1. 모든 인증서는 아래문서(키 관리 권장사항)의 섹션 5.6.1에 따라 최소 112비트의 대칭 키와 동등한 보안을 제공하는 개인 키를 사용합니다(SHALL).  이것은 NIST가 2011-2030년 기간 동안 권장하는 키 크기입니다.

National Institute of Standards and Technology. Special Publication 800-57 Part 1 Rev. 4, Recommendation for Key Management. January 2016. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final 

2. 1번 내용 중, RSA 또는 DSA 적용 조건에서, 키는 최소 2048비트 길이로 변환됩니다.

3. 1번 내용 중, elliptic curve cryptography(타원곡선 암호화)적용 조건에서, 키는 최소 224비트 길이로 변환됩니다.

4. 모든 암호화 작업은, 미래 시스템에적합한, 아래문서에서 BSI가 권장하는 알고리즘만을 사용해야 합니다(SHALL). 이 규정에는, 인증서 계층 구조의, 인증서 서명을 포함합니다.

Bundesamt für Sicherheit in der Informationstechnik: Anwendungshinweise und Interpretationen zum Schema, AIS 20, Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 3.0, Bonn, Germany, May 2013. (in German) https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20_pdf.html 

5. 인증 기관(CA: Certificate Authority)의 서명에는 RSA-PSS 또는 ECDSA를 사용해야 합니다(SHOULD).

6. 해시 값을 계산하려면 SHA256 알고리즘을 사용해야 합니다(SHOULD).

7. 인증서는 PEM(Privacy-Enhanced Mail) 형식으로 인코딩된 X.509 형식으로 저장 및 전송되어야 합니다(SHALL).

8. 모든 인증서에는 serial-number가 포함되어야 합니다(SHALL).

9. 인증서 subject 필드에 있는 O(organizationName) RDN(Relative Distinguished Name : 상대 고유 식별명)에, 인증서 소유자의 회사명(organization name)을 써(contain)야 합니다(SHALL).

10. CSMS 인증서의 경우, subject 필드는 CN(commonName) RDN에, 서버단의 FQDN(Fully Qualified Domain Name : 도메인명)을 포함해야 합니다(SHALL).

11. CS 인증서의 경우, subject 필드는 CS의 고유한 serial-number로 구성된 CN(commonName) RDN을 포함해야 합니다(SHALL). 이 일련 번호는 URL 또는 IP 주소 형식이 아니므로 충전소 인증서가 CSMS 인증서와 구별될 수 있습니다.

참고: RFC 2818에, dnsName 형식의 subjectAltName extension이 있으면, 그것을 ID로 사용해야 한다고 되어있습니다. 이 규정은 OCPP 및 ISO 15118과는 맞지 않습니다. 즉,  CS 및 CSMS 인증서에 사용해서는 안 됩니다(SHOULD NOT).

CSMS에 도달할 여러 네트워크 경로가 있는 경우 CSMS에 대해 dnsName 형식의 subjectAltName extension을 사용할 수 있습니다.

(예를들면, 사설 APN + (VPN에서 자신의 IP 주소를 사용하는) VPN의 경우, 그리고, 명명된 URL을 사용하는 공용 인터넷의 경우 등)

12. 모든 인증서는, X.509 Key Usage extension를 사용하여, 등록된 목적으로만 사용하도록 제한해야 합니다(SHOULD).

13. CS 인증서가 ISO 15118 프로토콜의 SECC 인증서로도 사용되는 경우 인증서는 ISO15118-2의 요구 사항도 충족해야 합니다(SHOULD).

14. 모든 인증서는, ISO 15118 표준과 호환되도록, X.509 확장 Key Usage extension을 사용하지 않는 것을 강력히 권장합니다. 다른 메커니즘으로 대체할 수 있습니다.

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 디렉토리에서 찾을 수 있다.

러브앤드럭스 (Love & ohter drugs)

 앤 해서웨이는 ‘악마는 프라다를 입는다’ 라는 영화로 영어공부를 했기 때문에, 익히 알고 있었는데, 레미제라블이라는 뮤지컬 영화에서 코제트의 엄마(팡틴) 역할로 부르는 노래를 듣고 - 개성있게 생긴 친구가 연기 잘하는건 알았는데, 노래도 매우 잘하네! 하고, 인상 깊게 남게 되었다.

다른 앤 해서웨이의 작품을 찾다 보던 중에 알게된, 러브 앤 드럭스(2010) 라는 영화를 방금 보았다. (포스터에 끌려서 본건 아님. 아무튼 절대 아님. ㅎㅎ)

파킨슨병을 앓고있는 매기머독(앤 해서웨이)과, 여성들에게 인기많은 제이미 랜달(제이크 질런홀)의 관계를 시간의 흐름에 따라 잘 풀어낸 영화였다. 하지만 한국인의 정서와는 많이 다른 미국식 인간관계와, 그들의 문화를 모른다면 이해할 수 없는 순간순간의 농담들을 자막으로 전달하는데는 한계가 있을 수 밖에 없었던것 같다.  또, 남녀간의 사랑얘기이기 때문에, 베드씬은 빠질 수 없는 장면이고, 수위 높은 노출때문에 부모들과 자녀들이 함께 보기에는 어려워보인다.

어린 나이의 내가 봤다면, 앤 해서웨이는 예쁘고, 제이크 질런홀은 너무 잘생겼고, 둘이 어려움을 극복하고 예쁘게 사랑을 확인하고, 평생 함께 할것을 약속했다는 해피앤딩의 영화로, 재밌게 잘 봤다 하는 감상과, 비아그라 광고 영환가? 하고 끝났을법 하다.

하지만, 이제, 만 나이로도 속일 수 없는, 나이 앞에 5자가 확실하게 고정되는 한해를 시작하는 현 시점에서, 만약 이런 커플이 내 눈앞에 있다면, 현실의 전쟁터를 둘이 잘 극복 해 낼 수 있을 것이라고 축복해 줄 수 있을까? 시카고 학회?에 참석했을 때, 수십년 파킨슨병을 앓고있는 아내를 지켜온, 선배 커플 남편분의 스쳐가는 조언이 최선이라고 생각된다. - ‘호텔로 돌아가서 당장 짐 싸서 떠나라. 나도 아내를 사랑하지만, 다시 하라면 절대 못한다.’

이럴땐 문득, 나도 세상의 때가 많이 뭍은건가 하는 생각이 강하게 든다. 감성보다는 논리, 이성 또는 산술적인 재산상의 문제 (미국인데, 여주인공은 의료보험도 없었다. - 우리나라 의료보험 만세..) 와 같은 복잡한 생각이 영화를 보는 내내 머릿속에서 떠나지 않았다.

여주인공의 남주인공에 대한 계속된 밀어내기는, 사랑하는 사람이 자신때문에 격게 될, 앞으로 닥쳐 올, 힘들고 고될 수 밖에 없는 미래의 상황으로 힘들껄 알고, 자신이 그에게 부담이되는 상황을 만드는걸 싫어서 일것이다. 이 또한, 전형적인, 개인주의와 독립심을 중요하게 생각하는, 미국식 사고방식으로 보여진다.

영화속의 사건 하나 하나, 세세한 장면들의 관계를 자세하게 풀고 싶어하는 감독의 노력이 충분히 보여지지만, 110분 정도의 러닝타임으로는 좀 부족했나보다. 대사 한마디 후, 바뀌는 다음장면이 왜 나와야 하는지 이해하는데 몇초 정도의 버퍼링이 걸리는 장면이 몇몇 있었다. 또, 앤 해서웨이의 몸 사리지 않는 과감한 노출이 있음에도 불구하고, 잔 감정선까지 잘 표현한 세밀한 연기가 돋보여졌다. (아.. 이런 주제넘는 감상평은 이제 자제 해야겠다.) 아무튼 혼자 또는 애인과 보기에 괜찮은 영화였다.

p.s. 영어공부 더 해야겠다. 의학적인 대화 내용은 전혀 알아들을 수가 없다. ㅜ.ㅜ

나의 결과물

 40중-후반에 직장을 옮길 수 밖에 없는 상황이 되었을 때, 자존감이 심각하게 떨어져, 우울감과 함께 무기력증에 빠진 적이 있다.  나 자신의 존재 이유를 찾지 못했었고, 지금까지 내가 이루어 놓은것이 무엇인가에 대하여 심각하게 생각을 해 봤었다.

자신이 초라하게 보여지는것은 지금까지 살아오면서, 스스로 만들고, 이룩 해 놓은 결과물들이 나에게 귀속되지 않고, 모두 회사의것으로 남아있으며, 이 세상엔 오롯이 나 혼자만 남아있는듯한 느낌을 떨쳐내기가 힘들었기 때문이었다.

이를 극복하기 위한 방법으로 생각한것이, 지금이라도 늦지 않았으니, 내 이름으로 남길 수 있는 결과물들을 하나하나 만들어 나가야 겠다는 생각을하게 되었고, 계속 반복해서 생각 하다보니, 이제는 결심.. 이라는 단어를 사용해도 별 문제는 없어 보인다.

내가 앞으로 나의것 이라고 할 수 있는 결과물들을 만들 수 있는 가능성이 있는, 구체적인것 들을 생각 해 보면, 지금 하고있는 글쓰기와, 내가 지금까지 업으로 삼아왔었던, 프로그램 만드는 일을 계속 하면서, 내 이름으로된 프로그램을 만들어 볼 수 있겠다고 생각하였다.

생각하기와는 별도로, 실제로 실행을 이어나가는것은 전혀 다른 내용이었다.

앞으로, 조금씩이라도 시간을 내어, 구체적인 결과물을 만들어갈 수 있는 방법을 써 나가야겠다.

Google Home OAuth 연결 개념 [해석]

 

OAuth linking concept guide

OAuth 연결 형식은 implicit 와 authorization code flows이라는 두 가지 산업 표준 OAuth 2.0 flow 을 지원합니다. implicit code flows에서 Google은 사용자의 브라우저에서 authorization endpoint를 엽니 다. 로그인에 성공하면, long-lived access token을 Google에 반환합니다. 이 access token은 어시스턴트에서 Action으로 보내는 모든 요청에 포함됩니다.

아래와 같은 경우, OAuth linking 솔루션을 추천합니다.

  ㅇ 기존 사용중인 OAuth 2.0 서버가 있지만, Google의 프로토콜의 단일 ID 자동 연결 및 계정 생성 token exchange endpoint를 확장하지 못하는 경우. (예: intent 추가 = get intent = 이 endpoint로의 변수 생성 요청)

OAuth 연결이 적합한 솔루션인지 확인하려면 계정 연결 유형 선택 페이지를 참조하세요.

Key terms(핵심 용어)

OAuth 연결 작동 방식을 읽기 전에 다음 용어를 숙지하십시오.

• EndPoint : 끝점. 즉, IT 관점에서, SW의 최종 사용자가 사용하는 디바이스(PC, Mobile etc) 또는 사용자가 사용하는 SW (브라우저, App 등) 또는 그 화면 .  프로그램의 입장에선, 상대방 프로그램 으로 생각할 수 있음.
• flow : 일련의 처리 과정
• exchange token : 본래 토큰을 받기 위해선 여러 절차를 거치면서 주고받기 때문에 exchange(교환)이 맞으나, 결과적으로 토큰을 받기 때문에, '토큰 받기'로 번역하는것도 괜찮아 보임.
• prompt : cmd 프롬프트의 정의는 '명령어를 입력하여 어떤 작업을 수행하게하는 도구'임, 여기서는 사용자의 음성 명령을 입력하여, 작업을 수행하기위한 도구 ... 라는 개념이 맞는것 같음. 의역 하자면, '명령 입력 대기 상태' 라고도 볼 수 있을 것 같음.
• scene : 대화의 개별 상태를 나타냄. 주요 목적은 대화를 논리적 덩어리(chunk)로 구성하고 작업(tasks)을 실행하며 사용자에게 프롬프트를 반환함.

• user.verificationStatus: 현재 세션에 확인 된 사용자가 있는지 여부를 나타 내기 위해 시스템에서 설정하는 속성입니다.

• user.accountLinkingStatus: 현재 세션의 사용자에게 연결된 ID가 있는지 여부를 나타 내기 위해 시스템에서 설정하는 속성입니다.

• 계정 연결 시스템 scene : 계정 연결 flow 확인을 위해 구현된, 또는 특정 사용 사례에 맞게 사용자 지정할 수있는 사전 정의 된 scene입니다.

• Authorization code flow : OAuth 2.0 flow를 처리하는 동안, Google은 사용자의 브라우저에서 인증 엔드 포인트를 엽니 다. 로그인에 성공하면 서비스에서 인증 코드를 생성 하여 Google에 반환합니다. Google은이 인증 코드를 토큰 교환 엔드 포인트로 전송하여 코드의 신뢰성을 확인하고 액세스 토큰 및 새로 고침 토큰을 반환합니다.

이 흐름에는 두 개의 끝 점이 필요합니다.

• Authorization(권한 부여) EndPoint : 데이터 액세스를 위해 사용자로부터 동의를 얻는 것을 담당하는 끝점입니다. 이 끝점은 다음을 수행합니다.
  1. 아직 로그인하지 않은 사용자에게 로그인 UI를 표시합니다.
  2. short-lived authorization code 형식의 접근 요청에 대한 동의내역을 기록합니다.
• Token exchange endpoint : 서비스를 사용하려는 Action user에게 권한을 부여한 'token' 이라는 암호화 된 문자열을 얻는 데 사용됩니다 . 이 endpoint는 두 가지 유형의 교환을 담당합니다.
  1. 장기 refresh token 및 단기 access token에 대한 인증 코드를 교환합니다. 이 교환은 사용자가 계정 연결 flow을 수행할 때 발생합니다.
  2. 수명이 긴 refresh token을 수명이 짧은 access token으로 교환합니다. 이 교환은 Google이 만료 되었기 때문에 새 access token이 필요할 때 발생합니다.

• Implicit(암시적) code flow : 이 OAuth 2.0 flow 동안에 Google은 사용자의 브라우저에서 로그인 페이지를 엽니 다. 로그인에 성공하면 수명이 긴 access token을 Google에 반환합니다. 이 access token은 어시스턴트에서 Action(작업)으로 보내는 모든 request(요청)에 ​​포함됩니다. 이 흐름에는 로그인 페이지(권한 부여 끝점) 만 필요합니다.
• access token : 서비스에 사용자 데이터의 일부에 액세스 할 수있는 권한을 부여하는 토큰입니다. 액세스 토큰은 각 개별 사용자와 연결되어 있으며 추측 할 수 없어야합니다.
• refresh token : 단기 access token이 만료되면 새 access token을 받을 수 있는(교환되는) 토큰입니다.

작동 원리

이 섹션에서는 OAuth authorization code 및 implicit flow에 대한 일반적인 flow을 설명합니다. 다음 섹션 인 OAuth linking flow 에서는 OAuth에서 발생할 수있는 다양한 flow을 설명합니다.

authorization code flow은 다음과 같이 요약 할 수 있습니다.

1. 내 작업(action)은 사용자에게 자신의 계정을 서비스와 연결할 것인지 묻습니다.
2. 사용자가 계정 연결에 동의하면 Google은 사용자의 브라우저에서 인증 엔드 포인트(로그인 페이지)를 엽니 다. 만약, 음성 전용 기기에서 작업(action)의 인증 흐름(flow)이 시작되면 Google은 모바일 화면으로 이동하여 인증을 실행합이다.
3. 사용자가 로그인하고 (아직 로그인하지 않은 경우) API를 사용하여 데이터에 액세스 할 수있는 권한을 Google에 부여합니다 (아직 권한을 부여하지 않은 경우).
4. 서비스에서 인증 코드를 생성 하고, 요청(request)에 인증 코드를 첨부하여 사용자의 브라우저(로그인 화면)에서 다시 Google로 리디렉션하여 Google에 반환합니다.
5. Google은 - 코드의 신뢰성(authenticity)을 확인(verify)하고 access token 과 refresh token을 반환하는 - 토큰 교환 엔드 포인트로 인증 코드를 보냅니다 . access token은 서비스가 API에 액세스하기위한 자격 증명을 허가하는 단기 토큰입니다. refresh token은 access token이 만료되면, Google이 새 access token을 획득하기위하여, 저장하고 사용하는 수명이 긴 토큰입니다.
6. 사용자가 계정 연결 flow을 완료하면 어시스턴트에서 이행(fulfillment) 웹훅으로 전송되는 모든 후속 요청(subsequent request)에 액세스 토큰이 포함됩니다.

암시적(implicit) 코드 flow은 다음과 같이 요약 할 수 있습니다.

1. 내 작업(action)은 사용자에게 자신의 계정을 서비스와 연결할 것인지 묻습니다.
2. 사용자가 계정 연결에 동의하면 Google은 사용자의 브라우저에서 인증 엔드 포인트(로그인 페이지)를 엽니 다.
3. 사용자가 로그인하고 (아직 로그인하지 않은 경우) API를 사용하여 데이터에 액세스 할 수있는 권한을 Google에 부여합니다 (아직 권한을 부여하지 않은 경우).
4. 서비스는 액세스 토큰을 생성하고, 요청에 액세스 토큰을 첨부하여 브라우저의 Google 리디렉션으로, Google에 반환합니다.
5. 사용자가 계정 연결 흐름을 완료하면 Google은 서비스의 API를 호출하고 각 요청에 액세스 토큰을 첨부합니다. 서비스는 액세스 토큰이 Google에 API 액세스 권한을 부여하는지 확인한 다음 API 호출을 완료합니다.

기본적인 인증(authorization) 코드 flow은 다음과 같습니다.

1. 내 작업(action)은 사용자에게 자신의 계정을 서비스와 연결할 것인지 묻습니다.
2. 사용자가 계정 연결에 동의하면 Google은 사용자의 브라우저에서 인증 엔드 포인트를 엽니 다. 작업의 음성 전용 기기에서 흐름이 시작되면 Google은 실행을 전화로 이관합니다.
3. 사용자가 로그인하고 (아직 로그인하지 않은 경우) API를 사용하여 데이터에 액세스 할 수있는 권한을 Google에 부여합니다 (아직 권한을 부여하지 않은 경우).
4. 서비스는 인증 코드를 생성 하고 요청에 첨부 된 단기 인증 코드를 사용하여 사용자의 브라우저를 다시 Google로 리디렉션하여 Google에 반환합니다.
5. Google은 코드의 신뢰성을 확인하고 액세스 토큰 과 새로 고침 토큰을 반환하는 토큰 교환 엔드 포인트로 인증 코드를 보냅니다 . 액세스 토큰은 서비스가 API에 액세스하기위한 자격 증명으로 허용하는 단기 토큰입니다. 새로 고침 토큰은 만료 될 때 Google이 새 액세스 토큰을 획득하는 데 저장하고 사용할 수있는 수명이 긴 토큰입니다.
6. 사용자가 계정 연결 흐름을 완료하면 어시스턴트에서 이행 웹훅으로 전송되는 모든 후속 요청에 액세스 토큰이 포함됩니다.

OAuth 연결 흐름

이 섹션에서는 OAuth 연결에서 발생할 수있는 다양한 flow에 대해 설명합니다.

참고 : 다음 flow들은 사용자가 계정을 귀하의 서비스와 연결하고, API를 사용하여 데이터에 액세스 할 수있는 권한을 Google에 부여하는 데 동의한다고 가정합니다. 사용자가 동의하지 않는 경우, 제한적인  flow로 대체하여, 작업(action)을 계속할 수있는 방법을 제공합니다. 자세한 내용은 모범 사례를 참조하십시오 .

각 flow에는 사용자가 작업을 호출 한 후 다음과 같은 일반적인 단계가 포함됩니다.

참고 : Webhook 에서 User로 연결되는 줄은 사용자가 만들고 사용자 지정 하는 간단한 응답 을 나타냅니다 . 어시스턴트 에서 사용자로 그려진 선은(??? 방향 오류같음) 어시스턴트 가 소유하고 사용자 정의 옵션이 제한된 프롬프트(즉시실행??)를 나타냅니다 (권한이 필요한 요청은 항상 어시스턴트가 소유 함). 사용자 관점에서 두 종류의 응답은 모두 Assistant에서 제공됩니다.

위의 flow는, 계정 연결 시스템 scene으로 전환하고 사용자 정의 된 근거를 제공합니다. 어시스턴트는 사용자에게 자신의 계정을 서비스에 연결할 것인지 묻고 요청 된 권한이있는 화면을 표시합니다. 사용자가 동의하면 Google은 사용자를 브라우저의 서비스 승인 엔드 포인트로 리디렉션합니다. 사용자는 로그인 (또는 구성에 따라 새 계정 생성)하고 데이터에 액세스 할 수있는 작업 권한을 부여합니다.

이 시점 이후의 흐름은 암시 적 흐름 또는 권한 부여 코드 흐름을 구현했는지 여부에 따라 다릅니다. 이러한 흐름은 다음 섹션에서 설명합니다.

Flow 1: User signs in with implicit flow

Note: This diagram builds off of the Common steps diagram above.

사용자가 로그인하고 자격 증명이 확인되면 서비스에서 수명이 긴 액세스 토큰을 만들고이를 Google에 반환합니다. 이 시점에서 작업의 사용자 ID는 로그인 한 계정에 연결되고 액세스 토큰은 Google이 서비스의 API에 수행하는 각 API 호출에 연결됩니다.

Flow 2: User signs in with authorization code flow

Note: This diagram builds off of the Common steps diagram above.

사용자가 로그인하고 자격 증명이 확인되면 서비스에서 인증 코드를 생성하여 Google에 반환합니다.

이 인증 코드는 액세스 토큰과 새로 고침 토큰을 모두 반환하는 토큰 교환 엔드 포인트로 전송됩니다. 이 시점에서 작업의 사용자 ID는 로그인 한 계정에 연결되며 어시스턴트에서 처리로 전송되는 모든 후속 요청에는 액세스 토큰이 포함됩니다.