ต่อ API กับ KBank — EP.1 เตรียมความพร้อมด้วย Two Way SSL

ในปัจจุบันเทคโนโลยีทางการเงินกำลังเปลี่ยนแปลงไปอย่างรวดเร็ว เราเล็งเห็นความร่วมมือระหว่างสถาบันการเงินและบริษัทต่างๆ ที่เริ่มมีการเชื่อมต่อ แบ่งปันการเข้าถึงข้อมูลและบริการต่างๆร่วมกัน โดยมีวัตถุประสงค์เพื่อพัฒนาการให้บริการดียิ่งขึ้นกว่าเดิมหรือเพื่อนำเสนอผลิตภัณฑ์ที่สร้างประสบการณ์ใหม่ๆ ให้กับลูกค้า ดังนั้นการแลกเปลี่ยนข้อมูลและการเปิดให้เข้าถึงบริการต่างๆ ทางการเงินด้วยความปลอดภัยและรวดเร็วจึงเป็นเรื่องสำคัญ ซึ่งเราสามารถทำได้ผ่าน API

API คืออะไร?

Photo by https://www.wrike.com/blog/application-programming-interface-api-explained/

API หรือเรียกชื่อเต็มว่า Application Programming Interface เป็นสิ่งที่เกิดขึ้นมานานแล้ว ไม่ใช่เรื่องใหม่แต่อย่างใด เพียงแต่รูปแบบในอดีตอาจจะเป็นรูปแบบ Private API ซึ่งส่วนใหญ่เป็นการเรียกใช้กันเองภายในองค์กร เช่น Application ต้องการจะส่งข้อมูลหรือแลกเปลี่ยนข้อมูลซึ่งกันและกันแบบออนไลน์ ภายหลังได้มีการเปิดกว้างทางเทคโนโลยีและเริ่มติดต่อสื่อสารกันระหว่างองค์กรมากขึ้นจนเกิดเป็น Open API ขึ้นมา จุดประสงค์คือเผยแพร่และแบ่งปันข้อมูลระหว่างองค์กรเพื่อสร้าง Ecosystem และพันธมิตรทางธุรกิจ

เมื่อมีการเชื่อมต่อระหว่างกัน เราจำเป็นต้องมีการกำหนดช่องทาง รวมถึงรูปแบบในการเชื่อมต่อ เช่น ผู้เรียกใช้งานต้องเรียกไปที่ไหน, Protocol ที่ใช้คืออะไร, Format ของข้อมูลเป็นแบบไหน, ความปลอดภัยในการเรียกใช้งานเป็นอย่างไร เช่น มีการเข้ารหัสหรือไม่, ต้องยืนยันตัวตนด้วยหรือเปล่า ฯลฯ ทั้งหมดนี้อยู่ภายใต้คอนเซ็ปต์ของ API

ตัวอย่างบริการผ่าน API

บริการ QR Payment Service เป็นบริการสร้างข้อมูล เพื่อให้ลูกค้าสามารถชำระค่าสินค้าและบริการในรูปแบบของ QR Code (Thai Standard) แบบ Dynamic โดย Partner ที่เชื่อมต่อมายัง API นี้สามารถกำหนดยอดเงิน จากนั้น API จะส่งข้อมูลกลับไปยัง Partner เพื่อทำการแปลงข้อมูลนั้นให้อยู่ในรูปแบบของ QR Code ลูกค้าก็สามารถใช้มือถือหรืออุปกรณ์อื่นๆ ที่สามารถอ่าน QR Code ในการชำระค่าสินค้าและบริการนั้นๆ

Open Banking คืออะไร? KBank/KBTG มีอะไรบ้าง?

Open Banking คือการที่ธนาคารเปิดกว้างมากยิ่งขึ้น โดยมีการเปิดให้บริการทางการเงินผ่าน API รวมถึงแบ่งปันข้อมูลและเทคโนโลยีต่างๆ แก่บุคคลที่สาม หรือ Partner ซึ่งอาจเป็นบริษัทที่ประกอบธุรกิจหรือสถาบันการเงินอื่นๆ ให้ธนาคารได้สร้างพันธมิตรทางธุรกิจ ในขณะที่ Partner ก็สามารถสร้างบริการใหม่ๆ ให้แก่ลูกค้าได้อย่างสะดวกและรวดเร็ว

ปัจจุบัน KBank และ KBTG ได้ออกผลิตภัณฑ์ API มาแล้ว 4 ผลิตภัณฑ์ คือ QR Payment, Inward Remittance, Information Sharing Service via K PLUS และ Slip Verification และยังมีแนวโน้มที่จะออกผลิตภัณฑ์ใหม่ๆ อย่างต่อเนื่อง โดยองค์กรหรือบุคคลภายนอกที่สนใจสามารถเข้ามาดูได้ที่ https://apiportal.kasikornbank.com/

ความปลอดภัยในการเชื่อมต่อ API

เมื่อธนาคารมีการเผยแพร่ข้อมูลและบริการต่างๆ ให้กับองค์กรหรือบุคคลภายนอกผ่าน API ความปลอดภัยและความเป็นส่วนตัวในการเข้าถึงข้อมูลนับว่าเป็นเรื่องที่สำคัญอย่างยิ่ง แน่นอนว่าเราไม่ต้องการให้ข้อมูลตกไปอยู่ในมือของผู้ที่ไม่มีสิทธิ์ในการเข้าถึงข้อมูลนั้นๆ ทางธนาคารจึงมีการตั้งมาตรฐานในการเชื่อมต่อ API ดังนี้

Photo by stormpath.com/blog/building-secure-apis-with-express

1. รับส่งข้อมูลผ่าน Secure Channel แบบ Two Way SSL โดยข้อมูลในการรับส่งจะถูกเข้ารหัสเพื่อความปลอดภัย และจะมีเพียงผู้ให้บริการเท่านั้นที่สามารถอ่านข้อมูลดังกล่าวได้
2. ในเมื่อเรารู้ว่าใครเป็นพันธมิตรของเรา ระบบจะอนุญาตการใช้งานเฉพาะรายการที่มาจาก IP Address ที่ทางพันธมิตรแจ้งไว้ รวมถึงมีการตรวจสอบ Certificate ที่ใช้ในการติดต่อธนาคาร เพื่อให้แน่ใจว่าต้นทางที่เรียก API เข้ามา มาจากแหล่งที่ธนาคารเชื่อถือเท่านั้น
3. มาตรฐานการยืนยันตัวตนด้วย OAuth 2.0 เป็นมาตรฐานการยืนยันตัวตนที่เป็นที่ยอมรับ เพื่อตรวจสอบสิทธิ์ของผู้เข้าใช้งานว่ามีสิทธิ์ในการเข้าถึงข้อมูลหรือบริการที่เรียกใช้งานจริงๆ

ว่ากันด้วยเรื่อง Two Way SSL

หลายท่านน่าจะพอรู้จักหรือเคยได้ยินมาตรฐานการรับส่งข้อมูลนี้กันมาบ้างแล้ว แต่เพื่อเป็นการปูพื้นฐานและนำไปสู่การเชื่อมต่อ API กับทางธนาคาร จึงขอนำเสนอพื้นฐาน รวมถึงการทำงานต่างๆ เพื่อให้พอเข้าใจตรงกัน โดยคำอธิบายจะเน้นในมุมมองของ Client หรือผู้ที่จะมาเชื่อมต่อ API กับทางธนาคารเป็นหลัก และการทำงานก็จะอธิบายในลักษณะที่ธนาคารกสิกรไทยได้เปิดให้บริการเป็นหลักเช่นกัน

Photo by marketingwithsara.com/affiliate-marketing/everything-affiliates-need-know-https-ssl-certificates

Two Way SSL (Secure Sockets Layer) หรือ Mutual TLS (Transport Layer Security) เป็นมาตรฐานการรับส่งข้อมูลผ่านเครือข่ายที่เหมาะกับการติดต่อแบบ Business-to-Business (B2B) Applications โดยจะมีการยืนยันตัวตนของทั้งสองฝ่าย คือ Server และ Client ผ่าน X.509 Certificate ที่แลกเปลี่ยนกัน รวมทั้งมีการเข้ารหัสข้อมูลที่ส่งจาก Client ไปสู่ Server ด้วย จึงมั่นใจได้ว่าลิงก์ในการรับส่งข้อมูลจะเป็นแบบส่วนตัว โดยจะทำผ่าน HTTPS Protocol และ Port มาตรฐานที่ใช้จะเป็น Port 443

ทำไมต้อง Two Way SSL?

ใน One Way SSL จะมีเพียงฝั่ง Client เท่านั้นที่จะทำการ Validate Server Certification ซึ่งเป็นการยืนยันตนของ Server เพียงทางเดียว ดังนั้นเพื่อเพิ่มความปลอดภัยสูงสุด ทางธนาคารจึงเลือกใช้ Two Way SSL เพื่อให้ฝั่ง Server มีสิทธิ์ตรวจสอบ Certificate ของผู้เรียกใช้งานได้ด้วยเช่นกัน ทำให้ธนาคารสามารถควบคุมและกำหนดสิทธิ์การเข้าถึง API ผ่านการตรวจ Client Certificate

สิ่งที่ Client ต้องจัดเตรียม

ในเบื้องต้นสิ่งที่ Client ต้องมี คือ Client Certificate และ Private Key ทั้งสองอย่างอาจจะอยู่ในไฟล์เดียวกัน เช่น ในรูปแบบ .pem, .pfx หรือแยกไฟล์กัน เช่น .key สำหรับ Private Key และ .cer, .crt, .pem สำหรับ Certificate ก็ได้

ก่อนเชื่อมต่อกับทางธนาคาร Client ต้องทำการจดทะเบียน Public Certificate ที่รองรับมาตรฐาน CA โดย Client จะได้รับทั้ง Certificate และ Private Key มา ให้จัดเก็บไว้ แล้วส่งเฉพาะ Client Certificate File ให้กับธนาคารเพื่อให้ธนาคารตรวจสอบและนำไปลงทะเบียน Truststore ไว้ เป็นการประกาศว่าหากมีการเชื่อมต่อเข้ามา ธนาคารสามารถเชื่อถือ Certificate ตัวนี้ของทาง Client และอนุญาตให้เรียกใช้ API ได้

เริ่มการเชื่อมต่อแบบ Two Way SSL

ก่อนที่จะมีการรับส่งข้อมูล จะมีการทำ TLS/SSL Handshaking เพื่อยืนยันตัวตนของทั้งสองฝั่งผ่านการแลกเปลี่ยน Certificate และตรวจสอบซึ่งกันและกัน โดยขั้นตอนการประมวลผลต่างๆ เป็นดังต่อไปนี้

Photo by https://docs.apigee.com/api-platform/system-administration/about-ssl

1. Client จะเริ่มส่ง Request Message ไปหา Server
2. Server จะตอบกลับมาด้วย Server Certificate ซึ่งบรรจุ Public Key อยู่ภายใน โดย Certificate จะมาจาก Server Keystore ซึ่งมี Private Key อยู่ด้วย แต่ตัว Private Key จะไม่มีการส่งหา Client
3. Client ส่ง Client Certificate ของตนให้กับทาง Server ซึ่งบรรจุ Public Key อยู่ภายใน โดย Certificate จะมาจาก Client Keystore ซึ่งมี Private Key อยู่ด้วย แต่ตัว Private Key จะไม่มีการส่งหา Server
4. Client ทำการตรวจสอบยืนยัน Server Certificate ในกรณีที่ Certificate เป็น Signed Cert หรือ Cert ที่จดทะเบียนมา Client จะส่ง Request ไปที่ Certificate Authority (CA) เพื่อทำการตรวจสอบและยืนยัน Certificate (Certificate ของธนาคารกสิกรไทย เป็น Signed CA Certificate)
5. Server ทำการตรวจสอบยืนยัน Client Certificate หากพบว่า Certificate มีการลงทะเบียนไว้ใน Truststore เรียบร้อยแล้ว การยืนยันตัวตนก็จะสำเร็จ
6. Client และ Server มีการแลกเปลี่ยน Message เพื่อยืนยันและกำหนดการรับส่ง
7. Client เริ่มการส่งข้อมูลหา Server ผ่านการเข้ารหัส

วิธีทดสอบการเชื่อมต่อแบบง่ายๆ

ในการทดสอบเพื่อเรียก Endpoint แบบ Two Way SSL วิธีที่ง่ายที่สุด โดยที่เราไม่จำเป็นต้องเขียนโปรแกรมหรือติดตั้ง Tools ใดๆเลย คือการใช้ cURL หรือที่เรามักเรียกกันว่า Curl Command ครับ

cURL เป็น Free Client Command Line Tool ที่สามารถใช้ส่งข้อมูลผ่าน URL Syntax โดย cURL Support HTTPS และการทำ SSL Certificate Verification ต่างๆ ส่วนวิธีการเรียกนั้น เราสามารถใส่คำสั่งผ่าน Command Line ตรงๆ หรือจะทำเป็น Script เก็บไว้ เรียกใช้ในหลายโอกาสก็ได้ครับ ตัวอย่างคำสั่งจะเป็นตามด้านล่าง

curl -v --key kbank.test.2.key \
     --cert kbank.test.2.crt \
--location 
--request POST 'https://openapi-test.kasikornbank.com/exercise/ssl' \
--header 'x-test-mode: true' \
--header 'Content-Type: application/json' \
--header 'Content-Length: 0' \
--header 'Authorization: Bearer EW4iYcACWG4aFsXpGxr1F5AHQ5q3'

ผลลัพธ์ของ cURL

จากผลลัพธ์ของ cURL จะเห็นว่ามีการแสดงลำดับการทำ TLS/SSL Handshaking แล้วจบลงที่ SSL Certificate Verify Ok ซึ่งขั้นตอนหลังจากนี้ Client จะทำการส่ง Request Message ไปหา Server เพื่อประมวลผล แล้วจะได้ Response Message ตอบกลับมา ซึ่งตัว Response Message ก็จะแสดงผลด้านล่างต่อจากผลลัพธ์ในรูปเช่นกัน

สะดวกกว่าถ้าใช้ Tools แนะนำ Postman

Postman เป็นเครื่องมือที่ช่วยในการพัฒนา API โดยสามารถใช้ทดสอบการทำงานของ API Service ได้อย่างง่ายดาย ผ่าน User Interface ที่เข้าใจง่าย ผู้ใช้งานสามารถจำลองการส่งหรือเรียก API ได้ด้วยการกำหนด API Method (POST, GET, PUT), URL, ข้อมูลในส่วนของ Header และ Body แล้วกด “Send” เพียงเท่านี้ Postman จะทำการส่งรายการร้องขอออกไป เมื่อได้ผลลัพธ์กลับมาก็จะแสดงผลในส่วนล่างของหน้าจอแสดงผล พร้อมสรุป HTTP Code รวมถึง Response Time ต่างๆ ให้กับผู้ใช้งาน

หน้าจอของ Postman ที่แสดงคำขอและผลลัพธ์

กรณีที่ต้องการส่งแบบ Two Way SSL ต้องมีการระบุ Client Certificate and Private Key ที่จะใช้ก่อน โดยสามารถเข้าไปกำหนดได้ที่ Setting > Certificates > Add Certificate ให้ระบุ Domain ปลายทาง, Cert file, Key file เข้าไป

หน้อจอ Postman ในการกำหนด Client Certificate and Key

นอกจากนี้ใน Setting > General หัวข้อ “SSL Certificate Verification” ก็ควรจะเปิด “ON” อยู่ด้วยเช่นกัน เพื่อให้มีการ Verify Server Certificate เกิดขึ้น

ตัวอย่าง Source Code เพื่อเชื่อมต่อแบบ Two Way SSL

สุดท้ายนี้หากต้องเขียนโปรแกรมเพื่อเชื่อมต่อแบบ Two Way SSL ขออนุญาตยกตัวอย่างการเขียนแบบง่ายๆ โดยใช้ภาษา GO ในการสื่อความ เพราะภาษา GO กำลังเป็นที่นิยมอย่างมากใน KBTG รวมถึงผู้เขียนก็พอมีพื้นฐานอยู่บ้าง

ท่อนแรก (บรรทัดที่ 11–27) เป็นการกำหนดเพื่อเรียกใช้ Client Certificate File และ Private Key File เพื่อใช้ในการทำ Two Way SSL จากนั้นจะทำการเตรียม HTTP Client โดยนำ Cert มาใช้พร้อมระบุว่าต้องมีการ Verify Server Certificate

ท่อนหลัง (บรรทัดที่ 29–43) เป็นส่วนที่ทำการระบุ API Method POST, URL รวมถึง Content Header ต่างๆ ก่อนทำการส่งออก และนำผลลัพธ์ที่ได้กลับมาจาก Server มาแสดงผล

สรุปครับ

บทความนี้เป็นบทความแรกที่กล่าวถึงพื้นฐานและความสำคัญของ API ประกอบกับวัตถุประสงค์ของ KBank และ KBTG ที่กำลังพัฒนาผลิตภัณฑ์ API ต่างๆ เพื่อนำเทคโนโลยีและบริการต่างๆ ของธนาคารออกสู่ตลาดภายใต้คอนเซ็ปต์ Open Banking ส่วนในครึ่งหลังของบทความได้กล่าวถึงการเชื่อมต่อแบบ Two Way SSL เพื่อเป็นการปูพื้นฐานให้แก่ผู้ที่สนใจที่จะมาเชื่อมต่อ API กับทาง KBank และ KBTG สร้างความเข้าใจในเรื่องพื้นฐานการทำงาน พร้อมแนะนำแนวทางการทดสอบหรือเขียนโปรแกรมต่างๆ ไว้ด้วย เพื่อช่วยเหลือนักพัฒนามือใหม่ที่อาจจะยังไม่ทราบว่าจะเริ่มต้นอย่างไร โดยหวังเป็นอย่างยิ่งว่าบทความนี้จะมีประโยชน์ไม่มากก็น้อยครับ

สุดท้ายนี้… บทความนี้เป็นเพียงจุดเริ่มต้นในการให้ความรู้เกี่ยวกับ API เรายังคงมีเรื่องราวและความรู้อีกหลายเรื่องที่จะนำมาบอกเล่าในโอกาสต่อๆ ไปครับ โดยครั้งหน้าจะมากล่าวถึงการกำหนดสิทธิ์การเข้าถึง API ว่าทางธนาคารจะสามารถควบคุมการเข้าใช้งานได้อย่างไรบ้าง ไปจนถึงเรื่องเกี่ยวกับมาตรฐานการยืนยันตัวตนผ่าน OAuth 2.0 ที่ทางธนาคารเลือกใช้เป็นมาตรฐานหลักของเราครับ

ภาคผนวก: คำศัพท์ที่เกี่ยวข้องกับ Two Way SSL

1. Certificate คือใบรับรองอิเล็กทรอนิกส์ เป็นไฟล์ขนาดเล็ก ใช้เป็นส่วนหนึ่งในการทำ TLS/SSL ได้มาจากการจดทะเบียน โดยแนะนำให้จดเป็น Public Certificate เพราะจะได้รับการรับรองจาก Certificate Authority (CA) เพื่อใช้ในการยืนยันตัวตนกับฝั่ง Server ได้
2. Self-Signed Certificate คือใบรับรองอิเล็กทรอนิกส์ที่ถูกสร้างขึ้นเองและไม่ได้การรับรองจาก Certificate Authority (CA) โดยปกติจะสร้างขึ้นมาเพื่อใช้ในการรับส่งแบบส่วนตัว ไม่ได้ใช้ในทางธุรกิจ
3. Certificate Authority (CA) เป็นองค์กรหรือผู้ประกอบการที่ออกใบรับรองอิเล็กทรอนิกส์
4. Public Key ส่วนหนึ่งภายใน Certificate เป็น Key ที่ใช้เข้ารหัสในการรับส่ง โดยปกติแล้วฝั่ง Client จะได้รับสำเนา Public Key จากฝั่ง Server และฝั่ง Server จะมีสำเนา Public Key ของ Client เช่นกัน
5. Private Key คือ Key ที่ใช้ถอดรหัสข้อมูล
6. Keystore ใช้จัดเก็บ Certificate และ Private Key เพื่อใช้ในการทำ SSL
7. Truststore ใช้จัดเก็บ Certificate ที่มีความเชื่อถือและใช้ในการตรวจสอบยืนยัน Certificate ของฝั่งตรงข้ามในการทำ SSL

สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech