การพิสูจน์ตัวตนโทเค็นกับคุกกี้

อะไรคือความแตกต่างระหว่างการพิสูจน์ตัวตนโทเค็นและการพิสูจน์ตัวตนโดยใช้คุกกี้?

ฉันกำลังพยายามใช้งานEmber Auth Rails Demoแต่ฉันไม่เข้าใจเหตุผลเบื้องหลังการใช้การตรวจสอบความถูกต้องโทเค็นตามที่อธิบายไว้ในคำถามที่พบบ่อยของEmber Authสำหรับคำถาม "ทำไมต้องมีการตรวจสอบความถูกต้องโทเค็น"

การตรวจสอบเว็บทั่วไปส่วนใหญ่จะเป็นคนไร้สัญชาติเพราะของคำขอ / ตอบสนองธรรมชาติ โปรโตคอล HTTP เป็นตัวอย่างที่ดีที่สุดของโปรโตคอลไร้สัญชาติ แต่เนื่องจากเว็บแอปส่วนใหญ่ต้องการสถานะเพื่อที่จะรักษาสถานะระหว่างเซิร์ฟเวอร์และไคลเอนต์จึงมีการใช้คุกกี้เพื่อให้เซิร์ฟเวอร์สามารถส่งคุกกี้ในทุกการตอบกลับไปยังไคลเอนต์ ซึ่งหมายความว่าคำขอถัดไปจากไคลเอนต์จะรวมคุกกี้นี้และเซิร์ฟเวอร์จะรับรู้ วิธีนี้เซิร์ฟเวอร์สามารถรักษาเซสชันกับไคลเอนต์ไร้สถานะโดยรู้ทุกอย่างเกี่ยวกับสถานะของแอปเป็นส่วนใหญ่แต่เก็บไว้ในเซิร์ฟเวอร์ ในสถานการณ์นี้ไคลเอ็นต์ไม่ระงับในขณะนี้stateซึ่งไม่ใช่วิธีการทำงานของEmber.js

ใน Ember.js สิ่งต่างๆนั้นแตกต่างกัน Ember.js ทำให้งานของโปรแกรมเมอร์ง่ายขึ้นเพราะมันถือเป็นสถานะสำหรับคุณในไคลเอนต์โดยรู้ทุกขณะเกี่ยวกับสถานะโดยไม่ต้องร้องขอไปยังเซิร์ฟเวอร์เพื่อขอข้อมูลสถานะ

อย่างไรก็ตามบางครั้งสถานะการถือครองในไคลเอ็นต์อาจทำให้เกิดปัญหาการเกิดพร้อมกันซึ่งไม่ได้เกิดขึ้นในสถานการณ์ไร้สัญชาติ อย่างไรก็ตาม Ember.js เกี่ยวข้องกับปัญหาเหล่านี้สำหรับคุณด้วย โดยเฉพาะข้อมูลถ่านถูกสร้างขึ้นโดยคำนึงถึงสิ่งนี้ สรุปได้ว่า Ember.js เป็นเฟรมเวิร์กที่ออกแบบมาสำหรับไคลเอ็นต์แบบ stateful

Ember.js ไม่ทำงานเหมือนปกติไร้สัญชาติ app เว็บที่เซสชั่นที่รัฐและคุกกี้ที่เกี่ยวข้องได้รับการจัดการเกือบสมบูรณ์โดยเซิร์ฟเวอร์ Ember.js มีสถานะสมบูรณ์ใน Javascript (ในหน่วยความจำของไคลเอนต์ไม่ใช่ใน DOM เหมือนเฟรมเวิร์กอื่น ๆ ) และไม่จำเป็นต้องให้เซิร์ฟเวอร์จัดการเซสชัน ส่งผลให้ Ember.js มีความหลากหลายมากขึ้นในหลาย ๆ สถานการณ์เช่นเมื่อแอปของคุณอยู่ในโหมดออฟไลน์

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

ในความคิดของเหตุผลหลักว่าทำไมจะใช้การตรวจสอบโทเค็นแทนคุกกี้ที่ระบุไว้ในEmber Auth คำถามที่พบบ่อยเป็นหลักเนื่องจากลักษณะของกรอบ Ember.js และยังเพราะมันพอดีมากขึ้นด้วยstatefulกระบวนทัศน์ app เว็บ ดังนั้นกลไกคุกกี้จึงไม่ใช่แนวทางที่ดีที่สุดในการสร้างแอป Ember.js

ฉันหวังว่าคำตอบของฉันจะให้ความหมายกับคำถามของคุณมากขึ้น

Http ไร้สัญชาติ ในการอนุญาตคุณคุณต้อง "ลงชื่อ" ทุกคำขอที่คุณส่งไปยังเซิร์ฟเวอร์

การพิสูจน์ตัวตนโทเค็น

• คำขอไปยังเซิร์ฟเวอร์มีการลงนามโดย "โทเค็น" - โดยปกติจะหมายถึงการตั้งค่าส่วนหัว http เฉพาะอย่างไรก็ตามสามารถส่งในส่วนใดก็ได้ของคำขอ http (เนื้อหา POST ฯลฯ )

• ข้อดี:

  • คุณสามารถอนุญาตได้เฉพาะคำขอที่คุณต้องการอนุญาตเท่านั้น (คุกกี้ - แม้แต่คุกกี้การอนุญาตก็ยังถูกส่งไปสำหรับทุกคำขอ)
  • มีภูมิคุ้มกันต่อ XSRF (ตัวอย่างสั้น ๆ ของ XSRF - ฉันจะส่งลิงก์ในอีเมลให้คุณซึ่งจะมีลักษณะเช่น<img src="http://bank.com?withdraw=1000&to=myself" />นี้และหากคุณลงชื่อเข้าใช้ผ่านการตรวจสอบคุกกี้ไปที่ bank.com และ bank.com ไม่มี XSRF การป้องกันฉันจะถอนเงินออกจากบัญชีของคุณเพียงเพราะเบราว์เซอร์ของคุณจะเรียกคำขอ GET ที่ได้รับอนุญาตไปยัง URL นั้น) โปรดทราบว่ามีมาตรการต่อต้านการปลอมแปลงที่คุณสามารถทำได้ด้วยการตรวจสอบสิทธิ์โดยใช้คุกกี้ - แต่คุณต้องใช้สิ่งเหล่านี้
  • คุกกี้ถูกผูกไว้กับโดเมนเดียว โดเมน bar.com ไม่สามารถอ่านคุกกี้ที่สร้างบนโดเมน foo.com ได้ในขณะที่คุณสามารถส่งโทเค็นไปยังโดเมนใดก็ได้ที่คุณต้องการ สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับแอปพลิเคชันหน้าเดียวที่ใช้บริการหลายรายการที่ต้องได้รับอนุญาตดังนั้นฉันจึงมีเว็บแอปบนโดเมน myapp.com ที่สามารถส่งคำขอฝั่งไคลเอ็นต์ที่ได้รับอนุญาตไปยัง myservice1.com และ myservice2.com
• จุดด้อย:
  • คุณต้องเก็บโทเค็นไว้ที่ไหนสักแห่ง ในขณะที่คุกกี้ถูกจัดเก็บ "นอกกรอบ" ตำแหน่งที่อยู่ในใจคือ localStorage (ข้อเสีย: โทเค็นยังคงอยู่แม้ว่าคุณจะปิดหน้าต่างเบราว์เซอร์), sessionStorage (โปร: โทเค็นจะถูกทิ้งหลังจากคุณปิดหน้าต่างเบราว์เซอร์ข้อเสีย: การเปิดลิงก์ในแท็บใหม่จะทำให้แท็บนั้นแสดงผล ไม่ระบุชื่อ) และคุกกี้ (Pro: โทเค็นจะถูกละทิ้งหลังจากที่คุณปิดหน้าต่างเบราว์เซอร์หากคุณใช้คุกกี้เซสชันคุณจะได้รับการตรวจสอบสิทธิ์เมื่อเปิดลิงก์ในแท็บใหม่และคุณจะไม่ได้รับ XSRF เนื่องจากคุณไม่สนใจ คุกกี้สำหรับการตรวจสอบสิทธิ์คุณแค่ใช้เป็นที่จัดเก็บโทเค็น Con: คุกกี้จะถูกส่งออกไปสำหรับทุกคำขอหากคุกกี้นี้ไม่ได้ถูกทำเครื่องหมายเป็น https เท่านั้นคุณจะเปิดให้มนุษย์เข้าโจมตีได้)
  • มันง่ายกว่าเล็กน้อยในการโจมตี XSS จากการตรวจสอบความถูกต้องโดยใช้โทเค็น (กล่าวคือถ้าฉันสามารถเรียกใช้สคริปต์ที่แทรกบนไซต์ของคุณได้ฉันก็สามารถขโมยโทเค็นของคุณได้อย่างไรก็ตามการรับรองความถูกต้องตามคุกกี้ไม่ใช่กระสุนเงินเช่นกัน - ในขณะที่คุกกี้ถูกทำเครื่องหมายเป็น ไคลเอ็นต์ไม่สามารถอ่าน http เท่านั้นลูกค้ายังคงสามารถส่งคำขอในนามของคุณซึ่งจะรวมคุกกี้การให้สิทธิ์ไว้โดยอัตโนมัติ)
  • คำขอดาวน์โหลดไฟล์ซึ่งควรจะใช้ได้เฉพาะกับผู้ใช้ที่ได้รับอนุญาตคุณต้องใช้ File API คำขอเดียวกันนี้ใช้งานได้ทันทีสำหรับการตรวจสอบสิทธิ์โดยใช้คุกกี้

การตรวจสอบคุกกี้

• คำขอไปยังเซิร์ฟเวอร์จะถูกลงชื่อเข้าใช้โดยคุกกี้การอนุญาตเสมอ
• ข้อดี:
  • คุกกี้สามารถทำเครื่องหมายเป็น "http-only" ซึ่งทำให้ไม่สามารถอ่านได้ทางฝั่งไคลเอ็นต์ สิ่งนี้ดีกว่าสำหรับการป้องกันการโจมตี XSS
  • มาพร้อมกล่อง - คุณไม่จำเป็นต้องติดตั้งโค้ดใด ๆ ในฝั่งไคลเอ็นต์
• จุดด้อย:
  • ผูกพันกับโดเมนเดียว (ดังนั้นหากคุณมีแอปพลิเคชันหน้าเดียวที่ร้องขอบริการหลายรายการคุณสามารถทำสิ่งที่บ้าคลั่งเช่น reverse proxy ได้)
  • เสี่ยงต่อ XSRF คุณต้องใช้มาตรการเพิ่มเติมเพื่อให้ไซต์ของคุณได้รับการป้องกันจากการปลอมแปลงคำขอข้ามไซต์
  • จะถูกส่งออกไปทุกคำขอเดียว (แม้กระทั่งสำหรับคำขอที่ไม่ต้องการการตรวจสอบสิทธิ์)

โดยรวมแล้วฉันคิดว่าโทเค็นให้ความยืดหยุ่นที่ดีกว่า (เนื่องจากคุณไม่ได้ผูกพันกับโดเมนเดียว) ข้อเสียคือคุณต้องเขียนโค้ดด้วยตัวเอง

• โทเค็นต้องถูกเก็บไว้ที่ใดที่หนึ่ง (ที่เก็บข้อมูลในเครื่อง / เซสชันหรือคุกกี้)

• โทเค็นอาจหมดอายุได้เช่นเดียวกับคุกกี้ แต่คุณสามารถควบคุมได้มากกว่า

• พื้นที่เก็บข้อมูลในเครื่อง / เซสชันจะไม่ทำงานข้ามโดเมนใช้คุกกี้เครื่องหมาย

• คำขอ Preflight จะถูกส่งไปตามคำขอ CORS แต่ละรายการ

• เมื่อคุณต้องการสตรีมบางสิ่งให้ใช้โทเค็นเพื่อรับคำขอที่ลงชื่อ

• จัดการกับ XSS ได้ง่ายกว่า XSRF

• โทเค็นจะถูกส่งไปทุกคำขอระวังขนาดของมัน

• หากคุณจัดเก็บข้อมูลที่เป็นความลับให้เข้ารหัสโทเค็น

• JSON Web Token สามารถใช้ใน OAuth ได้

• โทเค็นไม่ใช่กระสุนเงินโปรดพิจารณากรณีการใช้งานการอนุญาตของคุณอย่างรอบคอบ

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

สำหรับ Googler :

• ไม่ผสมstatefulnessกับกลไกการถ่ายโอนรัฐ

สถานะ

• Stateful = บันทึกข้อมูลการอนุญาตในฝั่งเซิร์ฟเวอร์ซึ่งเป็นวิธีดั้งเดิม
• Stateless = บันทึกข้อมูลการอนุญาตในฝั่งไคลเอ็นต์พร้อมด้วยลายเซ็นเพื่อให้แน่ใจว่าสมบูรณ์

กลไก

• Cookie = ส่วนหัวพิเศษที่มีการดูแลเป็นพิเศษ (การเข้าถึงการจัดเก็บการหมดอายุความปลอดภัยการโอนอัตโนมัติ) โดยเบราว์เซอร์
• ส่วนหัวที่กำหนดเอง = เช่นAuthorizationเป็นเพียงส่วนหัวโดยไม่มีการดูแลเป็นพิเศษลูกค้าต้องจัดการทุกด้านของการถ่ายโอน
• อื่น ๆ อาจใช้กลไกการถ่ายโอนอื่น ๆ เช่นสตริงการสืบค้นเป็นตัวเลือกในการถ่ายโอน ID การตรวจสอบความถูกต้องในขณะหนึ่ง แต่ถูกละทิ้งเนื่องจากความไม่ปลอดภัย

การเปรียบเทียบสถานะ

• "การอนุญาตแบบระบุสถานะ" หมายถึงเซิร์ฟเวอร์จัดเก็บและรักษาข้อมูลการอนุญาตผู้ใช้บนเซิร์ฟเวอร์ทำให้การอนุญาตเป็นส่วนหนึ่งของสถานะแอปพลิเคชัน
• ซึ่งหมายความว่าไคลเอนต์จะต้องเก็บ "auth ID" ไว้เท่านั้นและเซิร์ฟเวอร์สามารถอ่านรายละเอียดการรับรองความถูกต้องจากฐานข้อมูลได้
• นี่หมายความว่าเซิร์ฟเวอร์เก็บกลุ่มของการตรวจสอบสิทธิ์ที่ใช้งานอยู่ (ผู้ใช้ที่เข้าสู่ระบบ) และจะค้นหาข้อมูลนี้สำหรับทุกคำขอ
• "การให้สิทธิ์แบบไม่ระบุสถานะ" หมายความว่าเซิร์ฟเวอร์ไม่ได้จัดเก็บและรักษาข้อมูลการตรวจสอบสิทธิ์ของผู้ใช้เพียง แต่ไม่รู้ว่าผู้ใช้รายใดลงชื่อเข้าใช้และต้องพึ่งพาไคลเอ็นต์ในการสร้างข้อมูลการตรวจสอบสิทธิ์
• ลูกค้าจะจัดเก็บข้อมูลการตรวจสอบสิทธิ์ที่สมบูรณ์เช่นคุณเป็นใคร (ID ผู้ใช้) และอาจเป็นสิทธิ์เวลาหมดอายุ ฯลฯ ซึ่งเป็นมากกว่า ID รับรองความถูกต้องดังนั้นจึงได้รับโทเค็นชื่อใหม่
• เห็นได้ชัดว่าไคลเอนต์ไม่สามารถเชื่อถือได้ดังนั้นข้อมูลการตรวจสอบความถูกต้องจะถูกจัดเก็บพร้อมกับลายเซ็นที่สร้างขึ้นhash(data + secret key)โดยที่คีย์ลับเท่านั้นที่รู้จักกับเซิร์ฟเวอร์ดังนั้นจึงสามารถตรวจสอบความสมบูรณ์ของข้อมูลโทเค็นได้
• โปรดทราบว่ากลไกโทเค็นเป็นเพียงการรับรองความถูกต้อง แต่ไม่ใช่การรักษาความลับลูกค้าจะต้องดำเนินการดังกล่าว
• นอกจากนี้ยังหมายความว่าลูกค้าที่ร้องขอทุกรายจะต้องส่งโทเค็นที่สมบูรณ์ซึ่งต้องใช้แบนด์วิดท์เพิ่มเติม

การเปรียบเทียบกลไก

• "คุกกี้" เป็นเพียงส่วนหัว แต่มีการทำงานที่โหลดไว้ล่วงหน้าในเบราว์เซอร์
• คุกกี้สามารถตั้งค่าโดยเซิร์ฟเวอร์และบันทึกอัตโนมัติโดยไคลเอนต์และจะส่งอัตโนมัติสำหรับโดเมนเดียวกัน
• คุกกี้สามารถถูกทำเครื่องหมายเพื่อhttpOnlyป้องกันการเข้าถึง JavaScript ของไคลเอ็นต์
• การดำเนินการที่โหลดไว้ล่วงหน้าอาจไม่พร้อมใช้งานบนแพลตฟอร์มอื่นนอกจากเบราว์เซอร์ (เช่นมือถือ) ซึ่งอาจทำให้ต้องใช้ความพยายามมากขึ้น
• "ส่วนหัวที่กำหนดเอง" เป็นเพียงส่วนหัวที่กำหนดเองโดยไม่มีการทำงานที่โหลดไว้ล่วงหน้า
• ลูกค้ามีหน้าที่รับผิดชอบในการรับจัดเก็บรักษาความปลอดภัยส่งและอัปเดตส่วนหัวที่กำหนดเองสำหรับแต่ละคำขอซึ่งอาจช่วยป้องกันการฝัง URL ที่เป็นอันตรายง่ายๆ

สรุปผล

• ไม่มีเวทมนตร์สถานะรับรองความถูกต้องจะต้องถูกเก็บไว้ที่ใดที่หนึ่งไม่ว่าจะที่เซิร์ฟเวอร์หรือไคลเอนต์
• คุณสามารถใช้งาน stateful / stateless กับคุกกี้หรือส่วนหัวที่กำหนดเองอื่น ๆ
• เมื่อผู้คนพูดถึงสิ่งเหล่านั้นความคิดเริ่มต้นของพวกเขาส่วนใหญ่: stateless = token + custom header, stateful = auth ID + cookie; นี่ไม่ใช่ทางเลือกเดียวที่เป็นไปได้
• พวกเขามีข้อดีข้อเสีย แต่แม้กระทั่งสำหรับโทเค็นที่เข้ารหัสคุณก็ไม่ควรเก็บข้อมูลที่ละเอียดอ่อน

ลิงค์

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

ดังนั้นผู้ใช้กังวลเกี่ยวกับวิธีที่ Google หรือ Facebook อาจใช้ข้อมูลคุกกี้ของตนอาจปิดคุกกี้ แต่พวกเขามีเหตุผลน้อยกว่าในการปิด Web Storage (จนกว่าผู้โฆษณาจะหาวิธีใช้สิ่งนั้นได้เช่นกัน)

นั่นคือความแตกต่างระหว่างคุกกี้ตามและโทเค็นหลังใช้ Web Storage

การพิสูจน์ตัวตนโดยใช้โทเค็นไม่มีสถานะเซิร์ฟเวอร์ไม่จำเป็นต้องจัดเก็บข้อมูลผู้ใช้ในเซสชัน สิ่งนี้ช่วยให้สามารถปรับขนาดแอปพลิเคชันได้โดยไม่ต้องกังวลว่าผู้ใช้ล็อกอินไว้ที่ไหนมี Web Server Framework affinity สำหรับคุกกี้ที่ใช้ในขณะที่ไม่เป็นปัญหากับโทเค็น ดังนั้นโทเค็นเดียวกันจึงสามารถใช้ในการดึงทรัพยากรที่ปลอดภัยจากโดเมนอื่นที่ไม่ใช่โดเมนที่เราล็อกอินซึ่งจะหลีกเลี่ยงการตรวจสอบสิทธิ์ uid / pwd อื่น

บทความที่ดีมากที่นี่:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

ใช้โทเค็นเมื่อ ...

ต้องการสหพันธ์ ตัวอย่างเช่นคุณต้องการใช้ผู้ให้บริการรายหนึ่ง (Token Dispensor) เป็นผู้ออกโทเค็นจากนั้นใช้เซิร์ฟเวอร์ api ของคุณเป็นตัวตรวจสอบโทเค็น แอปสามารถรับรองความถูกต้องกับ Token Dispensor รับโทเค็นจากนั้นนำเสนอโทเค็นนั้นไปยังเซิร์ฟเวอร์ API ของคุณเพื่อให้ได้รับการตรวจสอบ (ใช้ได้กับ Google Sign-In หรือ Paypal หรือ Salesforce.com เป็นต้น)

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

จำเป็นต้องมีการร้องขอ Cient Signed ที่นี่ลูกค้าจะลงนามคำขอโดยใช้คีย์ส่วนตัวและเซิร์ฟเวอร์จะตรวจสอบความถูกต้องโดยใช้คีย์สาธารณะที่ลงทะเบียนไว้แล้วของไคลเอนต์

ความแตกต่างหลักประการหนึ่งคือคุกกี้อยู่ภายใต้นโยบายแหล่งกำเนิดเดียวกันในขณะที่โทเค็นไม่ได้ สิ่งนี้จะสร้างเอฟเฟกต์ดาวน์สตรีมทุกประเภท

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

ในทางกลับกันโทเค็นจะออกและไม่อยู่ภายใต้นโยบายแหล่งกำเนิดเดียวกัน ผู้ออกสามารถเป็นใครก็ได้และขึ้นอยู่กับเจ้าภาพว่าจะเชื่อถือผู้ออกรายใด โดยทั่วไปผู้ออกเช่น Google และ Facebook จะได้รับความไว้วางใจเป็นอย่างดีดังนั้นโฮสต์จึงสามารถเปลี่ยนภาระในการพิสูจน์ตัวตนผู้ใช้ (รวมถึงการจัดเก็บข้อมูลความปลอดภัยของผู้ใช้ทั้งหมด) ไปยังบุคคลอื่นและผู้ใช้สามารถรวบรวมข้อมูลส่วนบุคคลของตนภายใต้ผู้ออกเฉพาะและไม่ต้องจำ รหัสผ่านที่แตกต่างกันจำนวนมากสำหรับแต่ละโฮสต์ที่โต้ตอบด้วย

สิ่งนี้ช่วยให้สามารถลงชื่อเพียงครั้งเดียวในสถานการณ์ที่ลดแรงเสียดทานโดยรวมในประสบการณ์ของผู้ใช้ ในทางทฤษฎีแล้วเว็บก็มีความปลอดภัยมากขึ้นเช่นกันเนื่องจากผู้ให้บริการข้อมูลประจำตัวเฉพาะปรากฏตัวขึ้นเพื่อให้บริการรับรองความถูกต้องแทนที่จะมีเว็บไซต์ ma และ pa ทุกแห่งที่สร้างระบบการรับรองความถูกต้องของตนเอง และเนื่องจากผู้ให้บริการเหล่านี้ต้องเสียค่าใช้จ่ายในการจัดหาทรัพยากรบนเว็บที่ปลอดภัยสำหรับแนวโน้มทรัพยากรขั้นพื้นฐานที่มีค่าเป็นศูนย์

ดังนั้นโดยทั่วไปโทเค็นจึงช่วยลดแรงเสียดทานและค่าใช้จ่ายที่เกี่ยวข้องกับการตรวจสอบความถูกต้องและเปลี่ยนภาระในด้านต่างๆของเว็บที่ปลอดภัยไปยังฝ่ายที่รวมศูนย์ซึ่งสามารถใช้งานและดูแลระบบรักษาความปลอดภัยได้ดีกว่า