OAuth 2.0 Bearer Token คืออะไร?

ตามRFC6750 -The OAuth 2.0 การอนุมัติกรอบ: ถือ Token การใช้งานถือเป็นโทเค็น:

โทเค็นการรักษาความปลอดภัยที่มีคุณสมบัติที่ฝ่ายใดฝ่ายหนึ่งครอบครองโทเค็น ("ผู้ถือ") สามารถใช้โทเค็นในลักษณะใด ๆ ที่บุคคลอื่น ๆ ที่ครอบครองสามารถ

สำหรับฉันคำจำกัดความนี้คลุมเครือและฉันไม่พบข้อมูลจำเพาะใด ๆ

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

ขอบคุณสำหรับตัวชี้ใด ๆ

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

Bearer Token สร้างขึ้นสำหรับคุณโดยเซิร์ฟเวอร์การตรวจสอบความถูกต้อง เมื่อผู้ใช้ตรวจสอบใบสมัครของคุณ (ลูกค้า) เซิร์ฟเวอร์การตรวจสอบแล้วก็ออกไปและสร้างสำหรับคุณ Token Bearer Tokens เป็นโทเค็นการเข้าถึงที่ใช้กับ OAuth 2.0 โทเค็นผู้ใช้โดยทั่วไปบอกว่า "ให้ผู้ถือการเข้าถึงโทเค็นนี้"

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

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

โทเค็น Refresh ของ Google มีลักษณะดังนี้: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

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

ปรับปรุง:

Bearer Token ถูกตั้งค่าในส่วนหัวการอนุญาตของทุกคำขอ Inline Action HTTP ตัวอย่างเช่น:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

สตริง"AbCdEf123456"ในตัวอย่างด้านบนคือโทเค็นการอนุญาตผู้ถือ นี่เป็นโทเค็นการเข้ารหัสที่สร้างขึ้นโดยเซิร์ฟเวอร์การตรวจสอบความถูกต้อง โทเค็นผู้ถือทั้งหมดที่ส่งพร้อมการดำเนินการมีฟิลด์ปัญหาโดยมีฟิลด์ผู้ชมที่ระบุโดเมนผู้ส่งเป็น URL ของฟอร์ม https: // ตัวอย่างเช่นถ้าอีเมลจาก noreply@example.com ผู้ชมเป็นhttps://example.com

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

Bearer Tokens เป็นส่วนหนึ่งของมาตรฐาน OAuth V2 และได้รับการยอมรับอย่างกว้างขวางจากหลาย API

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

แต่ดูเหมือนว่าคำถามของคุณกำลังพยายามค้นหาคำตอบเกี่ยวกับฟังก์ชันโทเค็นของ Bearer:

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

ดังนั้นฉันจะพยายามอธิบายว่าโทเค็นของผู้ถือและโทเค็นรีเฟรชทำงานอย่างไร:

เมื่อคำขอของผู้ใช้ไปยังเซิร์ฟเวอร์สำหรับผู้ใช้ส่งโทเค็นและรหัสผ่านผ่าน SSL ผลตอบแทนเซิร์ฟเวอร์สองสิ่ง: การเข้าถึงโทเค็นและรีเฟรชโทเค็น

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

Authorization: Bearer <access_token>

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

โทเค็นการเข้าถึงมีอายุสั้น ๆ (เช่น 30 นาที) หากราชสกุลเข้าถึงมีหมดอายุนานมันจะเป็นปัญหาเพราะในทางทฤษฎีมีความเป็นไปได้ที่จะยกเลิกมันไม่มี ลองจินตนาการถึงผู้ใช้ที่มีบทบาท = "ผู้ดูแลระบบ" ที่เปลี่ยนเป็น "ผู้ใช้" หากผู้ใช้เก็บโทเค็นเก่าไว้กับ role = "Admin" ผู้ใช้จะสามารถเข้าถึงโทเค็นหมดอายุด้วยสิทธิ์ของผู้ดูแลระบบ นั่นเป็นเหตุผลที่โทเค็นการเข้าถึงมีอายุสั้น

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

ราชสกุลรีเฟรชถูกเก็บไว้ในฐานข้อมูลและจะมีวันหมดอายุยาว (ตัวอย่าง: 1 เดือน)

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

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

ถือเป็นหนึ่งในโทเค็นหรือทำซ้ำมากขึ้นของตัวอักษรหลัก "-", "" , "_", "~", "+", "/" ตามด้วย 0 หรือมากกว่า "="

RFC 6750 2.1 ฟิลด์ส่วนหัวคำขอการให้สิทธิ์ (รูปแบบคือABNF (เพิ่ม BNF))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

ดูเหมือนว่า Base64 แต่ตามโทเค็นในส่วนหัวควรเข้ารหัส base64 หรือไม่ , มันไม่ใช่.

ขุดลึกบิตใน "HTTP / 1.1, ตอนที่ 7: การตรวจสอบ" ** แต่ผมเห็น b64token ที่เป็นเพียงความหมาย ABNF ไวยากรณ์เพื่อให้ตัวละครที่ใช้โดยทั่วไปใน base64, base64url ฯลฯ .. ดังนั้น b64token ไม่ กำหนดการเข้ารหัสหรือถอดรหัส แต่เพียงกำหนดตัวละครที่สามารถใช้ในส่วนของส่วนหัวการอนุญาตที่จะมีโทเค็นการเข้าถึง

อ้างอิง

• RFC 5234 3.6 การทำซ้ำตัวแปร: * กฎ
• RFC 2616 2.1 BNF ที่เพิ่มขึ้น