Tag: oauth2

  • TOTP Second-factor Auth and OAuth2 in ownCloud 10.2.1

    คิดว่าเรื่อง security หรือ ความปลอดภัย ในการใช้ username และ password ก็เป็นความรู้ที่น่าจะได้มาเล่าสู่กันฟัง ในครั้งนี้ผมได้ลองตั้งค่าการใช้ TOTP Second-factor Auth ร่วมกับ password ของ ownCloud ในหน้า login ที่ web page

    การใช้ TOTP Second-factor Auth ร่วมกับ password ก็คือ การที่แอดมินที่ดูแล ownCloud Server ได้เพิ่ม App ชื่อ 2-Factor Authentication ไว้เพื่อให้ user ได้เลือกเองว่าจะใช้งานหรือไม่ โดยแสดงเป็น option อยู่ในหน้า settings ของ user

    ข้างล่างนี้เป็น captured รูปภาพที่แอดมินเพิ่ม App TOTP Second-factor Auth โดยติดตั้งจาก Market

    ส่วนข้างล่างนี้เป็น captured รูปภาพเมื่อ user เลือกใช้ TOTP และ เข้าใช้งานผ่านเบราว์เซอร์ โดยใส่ TOTP ที่ได้จาก App บนมือถือ เช่น Google Authentication หรือ Microsoft Authentication เป็นต้น

    นอกจากนี้เราสามารถตั้งค่า App passwords สำหรับ ownCloud Desktop Client ดังรูป

    ส่วนข้างล่างนี้เป็น captured รูปภาพ ownCloud Desktop Client หากมีการตั้ง App passwords

    แต่ถ้าแอดมินเลือกติดตั้ง OAuth2 ก็จะทำให้การใช้งานทั้ง desktop client และ app บน smart phone นั้นมีความปลอดภัยมากขึ้น สะดวกมากขึ้น เพราะว่าจะเป็นการส่ง token ไปเก็บไว้แทนการเก็บ username และ password ไว้ใน app

    ข้างล่างนี้เป็น captured รูปภาพที่แอดมินเพิ่ม App OAuth2

    ในครั้งแรกที่เข้าใช้ Desktop Client หรือ App จะมีหน้าเว็บเพจเด้งขึ้นมาให้ใส่ username กับ password เพียงครั้งเดียว และขอให้ผู้ใช้คลิก Authorize จากนั้นก็ใช้งานได้ตลอดแล้ว

    รูปแสดงว่า เรามีการเข้าใช้อุปกรณ์อะไรบ้าง

    ดังนั้น หากใช้ OAuth2 ก็ไม่จำเป็นต้องใช้ TOTP Second-factor Auth แล้วครับ

    สภาพแวดล้อมการทำงาน

    • ownCloud Server (ownCloud community) version 10.2.1 (stable) ติดตั้งบน Ubuntu 16.04 server และ
    • ownCloud Desktop client version 2.5.4 (build 11415) รันบน Windows 10 version 1903
  • การเชื่อมต่อ OAuth2 ด้วย WordPress

    อยาก  Login ด้วย OAuth2 กับ WordPress ต้องทำอย่างไร

    สำหรับตัวอย่างนี้จะทำการติดตั้งบน WordPress 5.1 ผ่าน Plugin Simple Single Sign On

    • หลังจากติดตั้ง WordPress เสร็จ เข้าหน้า Administrator แล้วทำการกด Install เพื่อเข้าไปยังหน้าติดตั้ง Extension เพิ่มเติม ทำการเพิ่มปลั๊กอินใหม่ดังรูป

    • ทำการค้นหา single sign on และทำการ Install Now

    • จากนั้นทำการกด Activate

    • จากนั้นทำการตั้งค่าโดยข้าม Step 1 ไปตั้งค่า Step 2 เนื่องจากได้มีการตั้งค่า WP OAuth Server ให้รองรับไว้อยู่แล้ว

    • หลังจากนั้นทำการทดสอบ Login โดยกดปุ่ม Single Sign On

    เพิ่งเท่านี้ก็จะสามารถใช้งานได้ แต่ยังเป็นแบบเลือกได้ว่าจะ Login แบบ Local หรือผ่าน OAuth โดยอาจจะทำเป็นปุ่มในหน้าแรกเพื่อให้กด Login ก็ได้เช่นกัน

  • ทดสอบเชื่อมต่อ OAuth2 ด้วย Postman

    ต้องการทดสอบใช้งาน OAuth2 แต่ยังไม่รู้เลยว่าต้องทำยังไง

                 ถ้าต้องการทดสอบเบื้องต้นว่า OAuth2 ใช้งานอย่างไร หรือต้องการทดสอบอะไรบางอย่างก็สามารถใช้  Postman ทดสอบได้เลยครับ โดยไม่ต้องเขียนโปรแกรม ซึ่งก่อนอื่นต้องทำการติดตั้งโปรแกรมให้เรียบร้อยก่อนจาก Link : https://sysadmin.psu.ac.th/2017/04/23/postman

    •  ตัวอย่างการเชื่อมต่อแบบ Authorization Code

    • จากนั้นทำการกรอกรายละเอียด ซึ่งรายละเอียดทางผู้ดูแลจะแจ้งให้ทราบเมื่อขอเปิดใช้บริการ

    • จากนั้นจะปรากฎหน้าให้ Login เข้าสู่ระบบ
    • หลังจาก Login ก็จะปรากฎหน้า Token นำไปใช้ขอบริการข้อมูล
    • จะได้ access_token ไปใช้งาน โดยจากตัวอย่างจะเห็นว่ามีระยะเวลาหมดอายุ 3600 วินาที หรือ 1 ชม.นั่นเอง ส่วนคำว่า bearer เป็นชนิดของ Token ซึ่งชนิดมีผลต่อรูปแบบความปลอดภัยที่แตกต่างกัน ซึ่งจะไม่ได้กล่าวถึงรายละเอียด ลองไปศึกษาดูครับ


    ในส่วนของ OAuth2 แบบอื่น ๆ ศึกษาเพิ่มเติมได้จาก https://sysadmin.psu.ac.th/2017/04/23/what-is-oauth2/ รวมถึงตัวอย่างการเชื่อมต่อ OAuth2 กับ UserGrid ได้ที่ https://sysadmin.psu.ac.th/2017/04/19/auth-role-usergrid/

    ======================

    References :

    [1] https://sysadmin.psu.ac.th/2017/04/23/postman

    [2] https://sysadmin.psu.ac.th/2017/04/23/what-is-oauth2/

    [3] https://sysadmin.psu.ac.th/2017/04/19/auth-role-usergrid/

  • เรียนรู้เทคโนโลยี OAuth2

    OAuth2 คืออะไร ทำไมต้องใช้

                 OAuth2 คือมาตรฐานหนึ่งของระบบยืนยันตัวตน และจัดการสิทธิ์การเข้าใช้งานระบบต่าง ๆ เป็นมาตรฐาน rfc6747[1] ที่ใช้สำหรับ Client เชื่อมต่อกับ Server ที่ใช้ในการ Authen & Authorize เพื่อให้ได้รับสิ่งที่เรียกว่า Access Token เพื่อใช้แทน Username และ Password (สามารถใช้อย่างอื่นเพื่อขอ Token ก็ได้) เพื่อนำไปใช้กับบริการอื่น ๆ ทำให้มีความปลอดภัยมากขึ้น รวมถึงบอกว่าทำมีสิทธิ์ทำอะไรได้บ้างกับบริการนั้น ๆ (จริง ๆ แล้วถ้า Access Token หลุดก็เอาไปเข้าระบบอื่น ๆ ได้ อาจจะต่างตรงแค่ไม่เห็น Password) โดยแนะนำต้องใช้คู่กับ https อีกชั้นเพื่อความปลอดภัยสูงสุด โดยแสดงภาพคร่าว ๆ เป็น Protocol Flow ดังรูป[2]

                  โดย Access Token จะมีเวลาจำกัดในการใช้งานเมื่อ Token หมดอายุ ก็ต้องไปขอใหม่ เมื่อเลิกใช้งานก็ขอยกเลิก Token รูปแบบการใช้งานมี 4 รูปแบบหรือเรียกว่า grant_type โดยแต่ละแบบมีรายละเอียดดังนี้[3]

    1. Authorization Codeใช้สำหรับ Web Server ที่ใช้ Code ด้านหลังในการเชื่อมต่อกับ OAuth Server โดยไม่ได้เปิดเผยให้สาธารณะเห็น อธิบายเป็นลักษณะการใช้งานคือ
      – ผู้ใช้งานเข้า Web Site
      – จะมีให้กด Login Facebook, Twitter, Google หรืออื่น ๆ 
      – เมื่อผู้ใช้กดก็จะเด้งให้ไป Login ที่ผู้ให้บริการนั้น ๆ ถ้าเคย Login ไว้แล้วก็จะข้ามขั้นตอนนี้ไป
      – ถ้าผู้ให้บริการนั้น ๆ เช่น Facebook จะให้กดยอมรับข้ออนุญาต ส่วนมากจะถามเรื่องสิทธิ์ในการเข้าถึงข้อมูลส่วนตัว
      – เมื่อผู้ใช้กดอนุญาต ก็จะกลับมายัง Web Site โดยในเบื้องหลัง WebSite จะได้ authorization code มาเรียกร้อยแล้วจากผู้ให้บริการ
      – จากนั้นทาง Web Site ก็สามารถเข้าถึงข้อมูลของผู้ให้บริการนั้น ๆ ได้ตามสิทธิที่อนุญาตไว้


      วิธีใช้ authorization code

      1. มีปุ่ม login ซึ่งมี link มี parameter คล้ายๆแบบนี้
        https://[oauth-server]/authorize?response_type=code&client_id=testclient&client_secret=testpass&redirect_uri=http%3A%2F%2F10.1.0.20%3A32778%2F%3Fauth%3Dsso
      2. เมื่อกดปุ่ม login ระบบจะต้องแจ้งว่า จะขอใช้สิทธิเรื่องใดบ้าง

      3. เมื่อผู้ใช้กดตกลงอนุญาต หน้าจอจะถูกพาไปยัง redirect_uri ที่ระบุไว้ พร้อมทั้งส่ง authorization code มาให้ด้วย
      4. ซึ่งจะมีหน้าตาประมาณนี้
         https://yoursite.com/oauth/callback?code=xxx 
      5. อ่าน code ออกมาเพื่อนำไปขอ access_token กับ API ของผู้ให้บริการ login ตัวนั้นๆ
         POST https://api.blah.com/oauth/token?grant_type=authorization_code&code=xxx&redirect_uri=xxx&client_id=xxx&client_secret=xxx 
        

        ค่า client_id, client_secret โดยมาก เจ้าของ login API (Identity provider) จะเป็นคนกำหนดมาให้

        หลังจากส่ง code ด้วย HTTP method POST และบอกว่าเป็น grant_type แบบ authorization_code ไปแล้ว client จะได้ access_token กลับมา เราจะเอา access_token นั้นในการเรียก API อื่น ๆ ต่อไป

    2. Implicit

      ใช้สำหรับ App ฝั่ง Client ซึ่งไม่จำเป็นต้องมี Web Server เป็นเหมือนการคุยระหว่าง Web Browser Client กับ OAuth Server ตรง ๆ เหมาะกับพวกที่ลงท้ายด้วย JS เช่น ReactJS, AngularJS ที่ต้องการดึงข้อมูลด้วย Browser เลย (เหมาะกับ Mobile เป็นพิเศษ) ลักษณะการทำงานคล้าย ๆ กับข้อ 1 แต่จะต่างกันตรงไม่ต้องส่ง Client_Secret เป็นวิธีที่เปิดเผยให้สาธารณะเห็น

      วิธีใช้ Implicit

      1. สร้างปุ่ม login ที่ส่ง action ไปยัง URL แบบนี้
         https://login.blah.com/oauth?response_type=token&client_id=xxx&redirect_uri=xxx&scope=email 
      2. เมื่อผู้ใช้กดปุ่ม จะแสดงหน้าต่างขอใช้สิทธิ หากตกลงข้อมูลจะ submit ไป server แล้วข้อมูล token จะถูกส่งกลับมาตาม redirect_uri ที่กำหนดเอา
      3. client_id ในข้อ 1 id provider เป็นคนกำหนดมาให้
      4. token ที่ได้มา เอาไปใช้ได้ดึงข้อมูลตามสิทธิ์ที่ได้มาได้เลย
    3. Password Credentials

      ใช้สำหรับ Application ที่มีการจัดการสิทธิเอง แต่ต้องการยืนยันตัวตนเท่านั้น ซึ่งวิธีนี้ไม่ต้อง Redirect ไปที่ผู้ให้บริการอื่น วิธีนี้เหมาะกับการใช้งานที่เป็นบริการของตัวเอง เพราะ username password จะปรากฎในเครื่องที่ส่งขอ token ถ้าไปรันวิธีนี้บน Server อื่นที่ไม่ได้เป็นเจ้าของ แสดงว่า เขาอาจจะดักเอา username password ไปใช้ก็ได้


      การใช้ Password Credentials

      1. มี form รับ username/password เมื่อกด submit แล้ว ส่ง form submit (POST method) ไปยัง server/service ของเรา
         POST https://login.blah.com/oauth/token?grant_type=password&username=xxx&password=xxx&client_id=xxx 
      2. จะได้ access_token มาใช้งานได้เลยหากใส่ข้อมูลถูกต้อง
    4. Client Credentials

      ในกรณีที่เป็นการคุยระหว่าง Application -> Service โดยจะไม่เกี่ยวข้องกับผู้ใช้ ยกตัวอย่างว่าเราอาจจะได้ข้อมูลสักอย่างแต่ต้องการความปลอดภัยว่าต้องเป็นเครื่องที่เราให้สิทธิ์ ก็สามารถส่ง id และ secret ที่ออกให้ Application ส่งมาขอ token เพื่อเข้าถึง Service นั้น ๆ ได้เลย

    OAuth2 ปลอดภัยหรือไม่

          อยู่ที่การใช้งาน ว่าปลอดภัยหรือไม่ ถ้ารันบน http ธรรมดา ยังไงก็ไม่ปลอดภัย ถ้าใช้ php 4/5 หรือ windows 2003/2008/2008/2008 R2 ยังไงก็ไม่ปลอดภัย 

    แล้วทำไมต้องใช้ OAuth2

    – เนื่องจากเป็นมาตรฐานที่พัฒนาจาก OAuth1.0a ที่มีการใช้งานมาก ทำให้ Version 2 ซึ่งลดความซับซ้อนลง การใช้งานจึงเข้าใจง่ายขึ้น

    – เร็วกว่า xml web service ใช้ json ในการสื่อสาร เพราะขนาดข้อมูลที่ส่งจะเล็กกว่ามาก

    – มีผู้ให้บริการภายนอกหลากหลาย

    – เหมาะกับใช้งานที่หลากหลาย เพราะรองรับหลากหลายภาษา (Java, Python, Go, .NET. Ruby, PHP, .NET, ฯลฯ)

    – สามารถประยุกต์นำมาใช้งานเป็น Single Sign On ได้ (ต้องพัฒนาเพิ่มเอง ไม่มีมาให้ในมาตรฐาน)

    =================================================

    References :
    [1] The OAuth 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749

    [2] An Introduction to OAuth2 : https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

    [3] OAuth 2.0 clients in Java programming, Part 1, The resource owner password credentials grant : https://www.ibm.com/developerworks/library/se-oauthjavapt1/index.html

  • Workshop : PSU Passport OAuth2

    มีวิธี Authen แบบอื่นนอกจาก LDAP กับ Web Service ไหม

                ด้วยยุคสมัยเปลี่ยนไป ด้วยเทคโนโลยี OAuth2 ทำให้เราจำเป็นต้องศึกษาหาความรู้เพิ่มเติมกันอีกครั้งครับ

    หมายเหตุ : เนื่องจากต้องการให้เป็น Blog เปิดเผยได้ จึงขอไม่ระบุชื่อ Server จริง ๆ ลงไปนะครับ 


    โดยรวบรวม Blog แบ่งเป็น 7 Blog ดังนี้

    Blog ที่ ชื่อ Blog
         1 เรียนรู้เทคโนโลยี OAuth2
         2 การติดตั้ง Postman
         3 ทดสอบเชื่อมต่อ OAuth2 ด้วย Postman
         4 การเชื่อมต่อ OAuth2 ด้วย Joomla
         5 การเชื่อมต่อ OAuth2 ด้วย Wordpress
         6 การเชื่อมต่อ OAuth2 ด้วย .NET C#
         7 การเชื่อมต่อ OAuth2 ด้วย PHP (กำลังดำเนินการ)

    บทความและ Link เพิ่มเติม

    [1] การยืนยันตัวตนและกำหนดสิทธิ์ Apache UserGrid 2.x

    [2] รวม Code สำหรับเชื่อมต่อ OAuth ทุกภาษา 1 : https://oauth.net/code/

    [3] รวม Code สำหรับเชื่อมต่อ OAuth ทุกภาษา 2 : https://developer.byu.edu/docs/consume-api/use-api/follow-sample-code

  • การยืนยันตัวตนและการกำหนดสิทธิ์ Apache UserGrid 2.x

    ติดตั้ง UserGrid เสร็จแล้ว ถ้าจะใช้งานต้องทำอย่างไร

                 จากที่เคยกล่าวไปแล้วเบื้องต้นในวิธีติดตั้ง Apache UserGrid [1][2] จะมี Port สำหรับเรียกด้วย Rest Service คือ port 8080 ส่วนหน้าสำหรับบริหารจัดการจะเป็น 80 ซึ่งเบื้องต้นจะไม่ใช่ ssl ถ้าต้องการความปลอดภัยต้องไปปรับแต่งเพิ่มเติม (ถ้าใช้ ha-proxy ก็ทำ ssl เฉพาะด้านหน้าก็ได้ครับ) โดยอาจจะต้องปรับแต่งที่ตัว Tomcat อ่านเพิ่มเติมได้ที่ https://usergrid.apache.org/docs/installation/ug1-deploy-to-tomcat.html 

                 ในส่วนของบทความต่อไปนี้จะกล่าวถึง Authentication และ Permission ซึ่งรายละเอียดทั้งหมดอยู่ใน Web Usergrid : https://usergrid.apache.org/docs/security-and-auth/app-security.html

                   โดยระบบยืนยันตัวตนของ UserGrid จะใช้ OAuth 2.0 ซึ่งสรุปสั้น ๆ คือ Client ขอตั๋วเข้าใช้งาน (Token) โดยได้หลังจากยืนยันตัวตน จากนั้น Server ก็จะให้ตั๋วมาเมื่อยืนยันว่าเป็นตัวจริง จากนั้น Client ก็เอาตั๋วไปยื่นขอใช้งานระบบต่าง ๆ ต่อ โดยมีอีก 3 สิ่งที่ต้องรู้ดังนี้
    – Groups : คือการกำหนดกลุ่มของ User เพื่อกำหนดสิทธิ์ให้กลุ่ม แทนที่ต้องมากำหนดสิทธิ์ให้ทีละคน
    – Roles : คือการกำหนดสิทธิ์ว่าให้เข้าถึง Resource ใดได้บ้าง (User Profile, Application Data) ซึ่งสิ่งนี้จะเป็นตัวที่ต้องกำหนดให้แต่ละคน หรือแต่ละ Group
    – Permission : เมื่อมีสิทธิ์ใน Resource นั้นแล้วจะมีสิทธิ์ทำอะไรกับ Resource นั้นบ้าง (Select, Insert, Delete, Update)
    สำหรับการจัดการ Group, Role, Permission สามารถจัดการผ่าน Rest API ได้หมด แต่ในตัวอย่างที่จะเสนอจะทำการจัดการผ่าน UserGrid Admin Portal ดังนี้

    ตัวอย่างการเพิ่ม User ใหม่เข้าไปยัง Application ที่ต้องการ
    1) เลือก Application ที่ต้องการ จากนั้นเลือก User และกดปุ่มเพิ่ม

    2) กรอกรายละเอียดจากนั้นกด Create (รหัสผ่านเงื่อนไขเยอะจะตั้งยากหน่อย)

    ตัวอย่างการเพิ่มบัญชี test01 เข้าไปอยู่ใน Group CCStaffs

    1) สร้าง Group CCStaffs ขึ้นมาก่อน ดังรูป

      

    2) ทำการเพิ่ม User เข้าไปยัง Groups ซึ่งจริง ๆ แล้วทำได้ 2 แบบ คือ เข้าไปที่ User แล้วเพิ่ม Group หรือ เข้าไปที่ Group แล้วเพิ่ม User ดังรูป


    ตัวอย่างการเพิ่มบัญชี test01 เข้าไปอยู่ใน Role Guest
    1) เบื้องต้นจะมี Role ให้เลือก 3 Role แต่จะเลือก Role Guest ซึ่งจริง ๆ แล้วเป็นเหมือน Permission Template เพราะเราสามารถกำหนดสิทธิ์เพิ่มเติมนอกเหนือที่ระบุใน Role ได้อีกในภายหลัง (GET=Select,POST=Insert,PUT=Update,DELETE=Delete)

    2) ทำการเพิ่ม User เข้าไปยัง Roles ที่ต้องการ

                   ในส่วนของ DATA เมนูจะใช้ในการจัดการข้อมูล กล่าวง่าย ๆ คือ Database ของ App ซึ่งทั้งระบบ UserGrid จะเก็บเป็น Cassandar NoSQL Database ดังที่กล่าวไว้ในตอนก่อนหน้า โดยการเรียกใช้งาน หรือ Update ข้อมูลจะใช้ในรูปแบบ JSON ซึ่งเราสามารถ สร้าง แก้ไข ลบข้อมูลผ่าน Usergrid Admin Portal หรือจะทำผ่าน Rest API ก็ได้ แต่ถ้าผ่าน Rest API จะได้สิทธิ์ตาม Permission ที่ตั้งไว้

                   ในส่วนต่อไปจะกล่าวถึงวิธีการเรียก Authentication ผ่าน OAuth2 โดยจะทดสอบเรียกผ่าน curl (จะเรียกผ่าน Postman plugin chrome ก็ได้ครับ ตามสะดวกครับ) ก่อนอื่นมาทราบกันก่อนครับว่าเราจะยืนยันสิทธิ์แบบใดได้บ้าง (Organization->Application->User จากใหญ่ไปย่อย ๆ)

    • Application user : ใช้สิทธิ์ตามที่กำหนดในแต่ละ User
    • Application client : ให้สิทธิ์ทุกอย่างภายใต้ Application นั้น ๆ
    • Organization client : ให้สิทธิ์ทุกอย่างภายใต้ Organization นั้น ๆ
    • Admin user : ให้สิทธิ์ทุกอย่างในทุก ๆ Organization และ และ ทุก ๆ Application

    ตัวอย่างการเรียกใช้แบบ User Authentication (User Login)

    • ทำการเรียกผ่าน curl โดยต้องใส่ username และ password เข้าไปด้วย
    curl -X POST "https://api.usergrid.com/my-org/my-app/token" -d '{"grant_type":"password", "username":"john.doe", "password":"testpw"}'

    • ซึ่งเราสามารถนำ access_token เพื่อใช้ในการเข้าถึง path ต่าง ๆ ได้แล้ว แต่จะมีเวลา แค่ 604800 (24ชม.) สำหรับ token ดังกล่าว (วิธีเปลี่ยนลองถาม Google ดูครับ) ยกตัวอย่างต้องการดู User ทั้งหมดรวมทั้ง Profile ของทั้ง Application สามารถสั่งได้ดังนี้ (สามารถใส่ token ไปใน Header เลยก็ได้ ศึกษาเพิ่มเติมได้ที่ https://usergrid.apache.org/docs/security-and-auth/authenticating-api-requests.html)
    curl -X GET "https://api.usergrid.com/my-org/my-app/users?access_token=[access-token]"

    • จะเห็นว่าระบบฟ้องว่าเราไม่มีสิทธิ์ ซึ่งถ้าเราย้อนกลับไปดู Role Guest จะพบว่าเราไม่มีสิทธิ์ในการ GET ค่า path /users  ให้ทำการเพิ่มสิทธิ์ใน Permission ก่อน

    • ลองเรียกอีกครั้งจะได้ดังนี้

    ตัวอย่างการเรียกใช้แบบ Organization client authentication (ไม่แนะนำให้ใช้กับ Client->Server เหมาะกับ Server->Server มากกว่า)

    • จะต่างกับ User Authentication ตรงที่แทนที่จะส่ง User Password แต่จะส่ง Client ID และ Secret เพื่อขอ token แทน โดยจะได้สิทธิ์ทั้งหมดใน Application นั้น ๆ
      curl -X POST "https://api.usergrid.com/my-org/my-app/token" -d '{"grant_type":"client_credentials", "client_id":"[client-id]", "client_secret":"[client-secret]"}'
    • โดยเราสามารถดู Client ID และ Secret ได้ดังนี้

    • จากนั้นทดสอบขอ token ดังนี้

                 สำหรับการ Authentication แบบ Application นั้นค่อนข้างจะยุ่งยากกว่า ยังหาไม่ได้จาก Usergrid Admin Portal ต้องเรียกผ่าน curl ตั้งแต่สร้าง ถ้าใครจะศึกษาเพิ่มเติมหาได้ที่นี่ https://usergrid.apache.org/docs/orgs-and-apps/application.html (ผมขอยอมแพ้ในขั้นนี้)

                 ในการ Logout จะใช้วิธีการ Revoke token นั่นคือการทำให้ token หมดอายุนั่นเอง สามารถทำได้ง่าย ๆ ดังนี้

    curl -X PUT https://api.usergrid.com/your-org/your-app/users/someUser/revoketokens

    ตัวอย่างการเรียกใช้ Rest Service เพื่อ Logout

    ขอจบเพียงเท่านี้ก่อนครับ นี่ขนาดยังไม่เอาไปใช้จริงนะครับ (เห็นแล้วจะมีใครอยากใช้ไหมเนี้ย 555)

    =================================================

    References :
    [1] https://sysadmin.psu.ac.th/2017/04/07/usergrid-docker-containner/

    [2] https://usergrid.apache.org/docs