OAuth 2.0 มีหลายเวิร์กโฟลว์ ฉันมีคำถามสองสามข้อเกี่ยวกับทั้งสอง

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

ความแตกต่างระหว่างสองแนวทางในแง่ของความปลอดภัยคืออะไร? อันไหนปลอดภัยกว่าและทำไม?

ฉันไม่เห็นเหตุผลที่เพิ่มขั้นตอนพิเศษ (รหัสการอนุญาตแลกเปลี่ยนโทเค็น) ในเวิร์กโฟลว์เดียวเมื่อเซิร์ฟเวอร์สามารถออกโทเค็นการเข้าถึงได้โดยตรง

เว็บไซต์ต่างๆกล่าวว่าการไหลของรหัสการอนุญาตใช้เมื่อแอปไคลเอ็นต์สามารถรักษาข้อมูลรับรองได้อย่างปลอดภัย ทำไม?

นี่access_tokenคือสิ่งที่คุณต้องการเรียกใช้ทรัพยากรที่ได้รับการป้องกัน (API) ในโฟลว์รหัสการอนุญาตมี 2 ขั้นตอนในการรับ:

1. ผู้ใช้จะต้องรับรองความถูกต้องและส่งกลับcodeไปยังผู้บริโภค API (เรียกว่า "ลูกค้า")
2. "ไคลเอนต์" ของ API (โดยปกติคือเว็บเซิร์ฟเวอร์ของคุณ) แลกเปลี่ยนสิ่งที่codeได้รับใน # 1 สำหรับการaccess_tokenพิสูจน์ตัวตนด้วย a client_idและclient_secret
3. จากนั้นก็สามารถเรียก API access_tokenที่มี

ดังนั้นจึงมีการตรวจสอบอีกครั้ง: ผู้ใช้ที่เป็นเจ้าของทรัพยากรที่ปรากฏผ่าน API และไคลเอนต์ที่ใช้ API (เช่นเว็บแอป) ทั้งสองได้รับการตรวจสอบเพื่อการเข้าถึงที่จะได้รับ สังเกตเห็นลักษณะ "การอนุญาต" ของ OAuth ที่นี่: ผู้ใช้ให้สิทธิ์การเข้าถึงทรัพยากรของเขา (ผ่านการcodeส่งคืนหลังจากการตรวจสอบสิทธิ์) ไปยังแอปแอปรับaccess_tokenและส่งในนามของผู้ใช้

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

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

ฉันจะเพิ่มสิ่งที่นี่ซึ่งฉันไม่คิดว่าชัดเจนในคำตอบข้างต้น:

• Authorization-Code-Flow อนุญาตให้โทเค็นการเข้าถึงสุดท้ายไม่สามารถเข้าถึงและไม่เคยถูกเก็บไว้ในเครื่องด้วยเบราว์เซอร์ / แอพ รหัสการอนุญาตชั่วคราวจะมอบให้กับเครื่องด้วยเบราว์เซอร์ / แอพซึ่งจะถูกส่งไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์สามารถแลกเปลี่ยนกับโทเค็นการเข้าถึงแบบเต็มและเข้าถึง API เป็นต้นผู้ใช้ที่มีเบราว์เซอร์จะสามารถเข้าถึง API ผ่านเซิร์ฟเวอร์ด้วยโทเค็นเท่านั้น
• โฟลว์โดยนัยสามารถเกี่ยวข้องกับสองฝ่ายเท่านั้นและโทเค็นการเข้าถึงสุดท้ายถูกเก็บไว้บนไคลเอนต์ด้วยเบราว์เซอร์ / แอพ หากเบราว์เซอร์ / แอปนี้ถูกบุกรุกระบบจะตรวจสอบความถูกต้องซึ่งอาจเป็นอันตรายได้

TL; DRไม่ได้ใช้การไหลนัยถ้าคุณไม่ไว้ใจเครื่องผู้ใช้ราชสกุลถือ แต่คุณไม่ไว้วางใจเซิร์ฟเวอร์ของคุณเอง

ความแตกต่างระหว่างทั้งสองคือ:

1. ในโฟลว์โดยปริยายโทเค็นจะถูกส่งกลับโดยตรงผ่าน URL การเปลี่ยนเส้นทางที่มีเครื่องหมาย "#" และส่วนใหญ่จะใช้ในไคลเอนต์ javascript หรือแอปพลิเคชันมือถือที่ไม่มีฝั่งเซิร์ฟเวอร์ด้วยตนเองและลูกค้าไม่จำเป็นต้องเปิดเผยข้อมูล .

2. ในโฟลว์การให้สิทธิ์รหัสถูกส่งคืนด้วย "?" เพื่อให้สามารถอ่านได้โดยฝั่งเซิร์ฟเวอร์แล้วฝั่งเซิร์ฟเวอร์จะต้องให้ความลับกับลูกค้าในครั้งนี้เพื่อให้โทเค็น URL เพื่อรับโทเค็นเป็นวัตถุ json จากเซิร์ฟเวอร์การอนุญาต มันถูกใช้ในกรณีที่คุณมีแอพพลิเคชันเซิร์ฟเวอร์ที่สามารถจัดการกับโทเค็นนี้และจัดเก็บโทเค็นผู้ใช้กับโปรไฟล์ของเขา / เธอในระบบของเขาและส่วนใหญ่จะใช้สำหรับแอปพลิเคชันมือถือทั่วไป

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

การให้สิทธิ์โดยนัยนั้นคล้ายคลึงกับการให้สิทธิ์รหัสที่มีความแตกต่างสองประการ

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

ประการที่สองแทนเซิร์ฟเวอร์การอนุญาตที่ส่งคืนรหัสการอนุญาตซึ่งแลกเปลี่ยนสำหรับโทเค็นการเข้าถึงเซิร์ฟเวอร์การให้สิทธิ์จะส่งคืนโทเค็นการเข้าถึง

กรุณาหารายละเอียดได้ที่นี่ http://oauth2.thephpleague.com/authorization-server/which-grant/

การไหลโดยปริยาย

ข้อดี

• ง่ายที่สุดในการใช้

ข้อเสีย

• เข้าถึงโทเค็นที่มองเห็นได้ในเบราว์เซอร์
• ไม่สามารถระบุที่มาของโทเค็นการเข้าถึงได้
• โทเค็นการเข้าถึงไม่สามารถหมดอายุ (ตามนโยบายของ Google)

การไหลเวียนของรหัสอนุมัติ

ข้อดี

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

ข้อเสีย

• ต้องใช้จุดสิ้นสุดการตรวจสอบหลายรายการ

อ้างอิง: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

ให้ฉันสรุปประเด็นที่ฉันเรียนรู้จากคำตอบข้างต้นและเพิ่มความเข้าใจของฉันเอง

การไหลของรหัสการอนุญาต !!!

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

นัยแกรนไหล !!!

• เมื่อคุณไม่มี Web Application Server ให้ทำหน้าที่เป็น OAuth Client
• หากคุณไม่ต้องการการเข้าถึงที่ยาวนานเช่นต้องการการเข้าถึงข้อมูลชั่วคราวเท่านั้น
• หากคุณเชื่อถือเบราว์เซอร์ที่แอพของคุณทำงานและมีข้อกังวล จำกัด ว่าโทเค็นการเข้าถึงจะรั่วไหลไปยังผู้ใช้ที่ไม่น่าเชื่อถือ

อันไหนปลอดภัยกว่าและทำไม?

ทั้งสองอย่างปลอดภัยขึ้นอยู่กับสภาพแวดล้อมที่คุณใช้งาน

ฉันไม่เห็นเหตุผลที่เพิ่มขั้นตอนพิเศษ (รหัสการอนุญาตแลกเปลี่ยนโทเค็น) ในเวิร์กโฟลว์เดียวเมื่อเซิร์ฟเวอร์สามารถออกโทเค็นการเข้าถึงได้โดยตรง

มันเป็นเรื่องง่าย ลูกค้าของคุณไม่ได้เป็นที่เชื่อถือได้ เรามาดูรายละเอียดกันดีกว่า

พิจารณาว่าคุณกำลังพัฒนาแอปพลิเคชั่Instagram APIนดังนั้นคุณจึงลงทะเบียนแอปของคุณด้วยInstagramและกำหนดว่าAPI'sคุณต้องการอะไร Instagramจะช่วยให้คุณพร้อมclient_idและclient_secrect

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

Firstส่งคำขอไปInstagram Authentication Serverกับด้านล่างพารามิเตอร์

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

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

คุณได้รับและcode ที่นี่คือstatecodetemporaryและไม่ได้มีการบันทึกไว้ที่ใด

จากนั้นให้คุณsecondโทรไปInstagram API(จากเซิร์ฟเวอร์ของคุณ)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

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

ในการตอบสนองเราจะได้ access_token

จากมุมมองของการปฏิบัติ (สิ่งที่ผมเข้าใจ) เหตุผลหลักสำหรับการมีกระแสรหัส authz คือ:

1. การสนับสนุนสำหรับราชสกุลรีเฟรช (การเข้าถึงระยะยาวโดยแอปในนามของผู้ใช้) ไม่ได้รับการสนับสนุนในนัย: ดู: https://tools.ietf.org/html/rfc6749#section-4.2
2. การสนับสนุนสำหรับหน้าความยินยอมซึ่งเป็นสถานที่ที่เจ้าของทรัพยากรสามารถควบคุมการเข้าถึงที่จะให้ (ประเภทของการอนุญาต / หน้าการอนุญาตที่คุณเห็นใน google) เหมือนกันไม่ได้อยู่ที่นั่น ดูในส่วน: https://tools.ietf.org/html/rfc6749#section-4.1จุด (B)

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

นอกจากนั้นการใช้โทเค็นการรีเฟรชแอพสามารถเข้าถึงข้อมูลของผู้ใช้ได้ในระยะยาว

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

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

รุ่นที่ยาวกว่า:

ในต่อไปนี้ฉันจะติดกับ OAuth 2 คำศัพท์ที่กำหนดไว้ในRFC (มันอ่านอย่างรวดเร็ว): ทรัพยากรเซิร์ฟเวอร์ , ลูกค้า , เซิร์ฟเวอร์การอนุมัติ , การใช้ทรัพยากร

ลองนึกภาพคุณต้องการแอปของบุคคลที่สาม (= ไคลเอนต์) เพื่อเข้าถึงข้อมูลบางอย่างของบัญชี Google ของคุณ (= เซิร์ฟเวอร์ทรัพยากร) สมมติว่า Google ใช้ OAuth 2 คุณเป็นเจ้าของทรัพยากรสำหรับบัญชี Google แต่ตอนนี้คุณใช้งานแอปของบุคคลที่สาม

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

1. URL ของการเปลี่ยนเส้นทางนี้สิ้นสุดลงในประวัติเบราว์เซอร์ของการเปลี่ยนเส้นทางนี้จะจบลงในประวัติของเบราว์เซอร์ ดังนั้นเราจึงไม่ต้องการมีอายุการใช้งานยาวนานเข้าถึงโทเค็นการเข้าถึงได้โดยตรงที่นี่ รหัสการอนุญาตสั้น ๆ นั้นมีอันตรายน้อยกว่าในประวัติศาสตร์ โปรดทราบว่าโดยปริยายประเภทแกรนท์ไม่ใส่โทเค็นในประวัติศาสตร์
2. ความปลอดภัยของการเปลี่ยนเส้นทางนี้ขึ้นอยู่กับใบรับรอง HTTPS ของลูกค้าไม่ใช่ในใบรับรองของ Google ดังนั้นเราจึงได้รับการรักษาความปลอดภัยการส่งของลูกค้าเป็นเวกเตอร์การโจมตีพิเศษ (เพื่อหลีกเลี่ยงสิ่งนี้ลูกค้าจะต้องไม่ใช่จาวาสคริปต์เนื่องจากมิฉะนั้นเราสามารถส่งรหัสการอนุญาตผ่าน URL ส่วนซึ่งรหัสจะไม่ผ่านเครือข่าย นี่อาจเป็นสาเหตุที่ประเภทการให้สิทธิ์โดยนัยซึ่งไม่ใช้ URL ชิ้นส่วนที่ใช้ในการได้รับการแนะนำสำหรับลูกค้า JavaScript แม้ว่าที่ไม่ได้ดังนั้น.)

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