คำถามติดแท็ก oauth

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


14
เหตุใด OAuth v2 จึงมีทั้งโทเค็นการเข้าถึงและรีเฟรช
ส่วน 4.2 ของร่างโปรโตคอล OAuth 2.0 ระบุว่าเซิร์ฟเวอร์การอนุญาตสามารถส่งคืนทั้งสองได้ access_token (ซึ่งใช้ในการตรวจสอบสิทธิ์ของตัวเองด้วยทรัพยากร) เช่นเดียวกับ a refresh_tokenซึ่งใช้เพื่อสร้างใหม่อย่างแท้จริงaccess_token: https://tools.ietf.org/html/rfc6749#section-4.2 ทำไมถึงมีทั้งคู่? ทำไมไม่เพียงแค่ทำให้access_tokenครั้งสุดท้ายตราบเท่าที่refresh_tokenและไม่มีrefresh_token?

10
OAuth 2 แตกต่างจาก OAuth 1 อย่างไร
ในแง่ง่ายมากมีคนอธิบายความแตกต่างระหว่าง OAuth 2 และ OAuth 1 ได้ไหม OAuth 1 ล้าสมัยแล้วหรือยัง เราควรใช้ OAuth 2 หรือไม่ ฉันไม่เห็นการใช้งาน OAuth 2 มากมาย ส่วนใหญ่ยังคงใช้ OAuth 1 อยู่ซึ่งทำให้ฉันสงสัยว่า OAuth 2 พร้อมใช้งานแล้ว ใช่ไหม?

22
การตั้งค่าส่วนหัวการอนุญาตของ HttpClient
ฉันมี HttpClient ที่ฉันใช้สำหรับ REST API อย่างไรก็ตามฉันมีปัญหาในการตั้งค่าส่วนหัวการอนุญาต ฉันต้องตั้งส่วนหัวเป็นโทเค็นที่ฉันได้รับจากการทำตามคำขอ OAuth ของฉัน ฉันเห็นรหัสสำหรับ. NET ที่แนะนำสิ่งต่อไปนี้ httpClient.DefaultRequestHeaders.Authorization = new Credential(OAuth.token); อย่างไรก็ตามคลาส Credential ไม่มีอยู่ใน WinRT ใครมีแนวคิดใดบ้างที่จะตั้งค่าหัวข้อการให้สิทธิ์

6
วิธีรักษาความปลอดภัย ASP.NET Web API [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน3 ปีที่ผ่านมา ฉันต้องการสร้างบริการเว็บสงบโดยใช้ ASP.NET Web API ที่นักพัฒนาบุคคลที่สามจะใช้ในการเข้าถึงข้อมูลแอปพลิเคชันของฉัน ฉันได้อ่านค่อนข้างมากเกี่ยวกับOAuthและดูเหมือนจะเป็นมาตรฐาน แต่การหาตัวอย่างที่ดีพร้อมเอกสารอธิบายว่ามันทำงานอย่างไร (และนั่นใช้งานได้จริง!) ดูเหมือนจะยากอย่างไม่น่าเชื่อ มีตัวอย่างที่สร้างและใช้งานจริงและแสดงวิธีการใช้งานจริงหรือไม่? ฉันได้ดาวน์โหลดตัวอย่างมากมาย: DotNetOAuth - เอกสารเป็นสิ่งที่สิ้นหวังจากมุมมองของมือใหม่ Thinktecture - ไม่สามารถสร้างได้ ฉันยังได้ดูบล็อกที่แนะนำชุดรูปแบบโทเค็นที่เรียบง่าย (เช่นนี้ ) - นี่ดูเหมือนจะเป็นการประดิษฐ์วงล้อขึ้นใหม่ แต่มันมีข้อดีของการเป็นแนวคิดที่ค่อนข้างง่าย ดูเหมือนว่ามีคำถามมากมายเช่นนี้ใน SO แต่ไม่มีคำตอบที่ดี ทุกคนกำลังทำอะไรในพื้นที่นี้

9
อะไรคือความแตกต่างที่สำคัญระหว่างการตรวจสอบ JWT และ OAuth?
ฉันมี SPA ใหม่พร้อมโมเดลการพิสูจน์ตัวตนแบบไร้รัฐโดยใช้ JWT ฉันมักถูกขอให้อ้างถึง OAuth สำหรับกระบวนการตรวจสอบสิทธิ์เช่นขอให้ฉันส่ง 'โทเค็นโทเค็น' สำหรับทุกคำขอแทนที่จะเป็นส่วนหัวโทเค็นธรรมดา แต่ฉันคิดว่า OAuth นั้นซับซ้อนกว่าการรับรองความถูกต้อง JWT ธรรมดา อะไรคือความแตกต่างที่สำคัญฉันควรทำให้การตรวจสอบ JWT มีลักษณะเหมือน OAuth หรือไม่ ฉันใช้ JWT เป็น XSRF-TOKEN ของฉันเพื่อป้องกัน XSRF แต่ฉันถูกขอให้แยกพวกเขาหรือไม่ ฉันควรแยกพวกเขาออกจากกันหรือไม่? ความช่วยเหลือใด ๆ ที่นี่จะได้รับการชื่นชมและอาจนำไปสู่ชุดแนวทางสำหรับชุมชน

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

3
OAuth 2.0: ประโยชน์และการใช้เคส - ทำไม?
ใครสามารถอธิบายสิ่งที่ดีเกี่ยวกับ OAuth2 และทำไมเราควรนำไปใช้? ฉันถามเพราะฉันสับสนเล็กน้อยเกี่ยวกับมัน - นี่คือความคิดปัจจุบันของฉัน: คำขอ OAuth1 (HMAC ที่แม่นยำยิ่งขึ้น) นั้นดูสมเหตุสมผลเข้าใจง่ายง่ายต่อการพัฒนาและปลอดภัยจริงๆ OAuth2 นำคำขอการอนุญาตการเข้าถึงโทเค็นและรีเฟรชโทเค็นมาแทนและคุณจะต้องทำการร้องขอ 3 ครั้งในช่วงเริ่มต้นของเซสชันเพื่อรับข้อมูลที่คุณต้องการ และถึงตอนนั้นหนึ่งในคำขอของคุณก็จะล้มเหลวในที่สุดเมื่อโทเค็นหมดอายุ และเพื่อรับโทเค็นการเข้าถึงอื่นคุณใช้โทเค็นการรีเฟรชที่ถูกส่งไปในเวลาเดียวกันกับโทเค็นการเข้าถึง นั่นทำให้โทเค็นการเข้าถึงไร้ประโยชน์จากมุมมองความปลอดภัยหรือไม่? นอกจากนี้ตามที่ / r / netsec แสดงให้เห็นเมื่อเร็ว ๆ นี้ SSL นั้นไม่ได้ปลอดภัยทั้งหมดดังนั้นการผลักดันเพื่อให้ทุกอย่างเข้าสู่ TLS / SSL แทนที่จะเป็น HMAC ที่ปลอดภัยนั้นทำให้ฉันสับสน OAuth กำลังเถียงว่าไม่ใช่เรื่องความปลอดภัย 100% แต่ให้ตีพิมพ์และเสร็จสิ้น แต่นั่นไม่ได้เสียงที่แน่นอนว่าจากมุมมองของผู้ให้บริการ ฉันสามารถเห็นสิ่งที่ร่างพยายามที่จะบรรลุเมื่อมันกล่าวถึงกระแสที่แตกต่างกัน 6 แต่มันก็ไม่เหมาะกันในหัวของฉัน ฉันคิดว่ามันอาจเป็นการยากกว่าที่ฉันจะเข้าใจว่ามันมีประโยชน์และเหตุผลมากกว่าการไม่ชอบมันดังนั้นนี่อาจเป็นการโจมตีที่ไม่สมเหตุสมผลและขออภัยถ้าสิ่งนี้ดูเหมือนจะคุยโว
256 oauth  oauth-2.0 

12
ประเภทการให้สิทธิ์โดยนัยในวัตถุประสงค์ของ OAuth 2 คืออะไร
ฉันไม่รู้ว่าฉันเพิ่งมีจุดบอดหรืออะไร แต่ฉันอ่าน OAuth 2 สเป็คหลาย ๆ ครั้งและอ่านคลังเก็บรายชื่อผู้รับจดหมายแล้วและฉันยังไม่พบคำอธิบายที่ดีว่าทำไม Implicit Grant โฟลว์เพื่อรับโทเค็นการเข้าถึงได้รับการพัฒนา เมื่อเทียบกับการให้สิทธิ์รหัสอนุญาตดูเหมือนว่าจะยอมแพ้ในการตรวจสอบสิทธิ์ไคลเอ็นต์โดยไม่มีเหตุผลที่น่าสนใจ "วิธีนี้ได้รับการปรับให้เหมาะสมสำหรับลูกค้าที่ใช้งานในเบราว์เซอร์โดยใช้ภาษาสคริปต์" (เพื่ออ้างอิงข้อกำหนด) การไหลทั้งสองเริ่มเหมือนกัน (ที่มา: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ): ไคลเอ็นต์เริ่มต้นโฟลว์โดยสั่งให้เอเจนต์ผู้ใช้ของเจ้าของทรัพยากรไปยังจุดสิ้นสุดการให้สิทธิ์ เซิร์ฟเวอร์การอนุญาตรับรองความถูกต้องของเจ้าของทรัพยากร (ผ่านตัวแทนผู้ใช้) และสร้างว่าเจ้าของทรัพยากรมอบหรือปฏิเสธคำขอการเข้าถึงของลูกค้าหรือไม่ สมมติว่าเจ้าของทรัพยากรให้สิทธิ์การเข้าถึงเซิร์ฟเวอร์การอนุญาตเปลี่ยนเส้นทางผู้ใช้ตัวแทนกลับไปยังลูกค้าโดยใช้การเปลี่ยนเส้นทาง URI ที่ให้ไว้ก่อนหน้านี้ (ในคำขอหรือระหว่างการลงทะเบียนลูกค้า) URI การเปลี่ยนเส้นทางมีรหัสการอนุญาต (โฟลว์รหัสการอนุญาต) URI การเปลี่ยนเส้นทางรวมถึงโทเค็นการเข้าถึงในส่วนของ URI (โฟลว์โดยนัย) นี่คือที่ที่กระแสแยก ในทั้งสองกรณี URI การเปลี่ยนเส้นทาง ณ จุดนี้คือจุดปลายทางที่โฮสต์โดยลูกค้า: ในโฟลว์การอนุญาตเมื่อเอเจนต์ผู้ใช้พบจุดสิ้นสุดนั้นด้วยโค้ดการอนุญาตใน URI โค้ดที่จุดปลายนั้นจะแลกเปลี่ยนโค้ดการอนุญาตพร้อมกับหนังสือรับรองไคลเอ็นต์สำหรับโทเค็นการเข้าถึงซึ่งสามารถใช้งานได้ตามต้องการ ตัวอย่างเช่นสามารถเขียนลงในหน้าเว็บที่สคริปต์บนหน้าสามารถเข้าถึงได้ โฟลว์โดยปริยายจะข้ามขั้นตอนการพิสูจน์ตัวตนลูกค้าทั้งหมดและเพียงโหลดหน้าเว็บด้วยสคริปต์ลูกค้า มีเคล็ดลับน่ารักอยู่ที่นี่ด้วยส่วน URL ที่ทำให้ไม่สามารถส่งโทเค็นการเข้าถึงได้มากเกินไป แต่ผลลัพธ์สุดท้ายก็เหมือนกัน: ไซต์ที่โฮสต์โดยไคลเอ็นต์ให้บริการหน้าเว็บที่มีสคริปต์บางตัวที่สามารถเข้าถึงโทเค็นการเข้าถึงได้ . ดังนั้นคำถามของฉัน: …

28
Facebook OAuth“ โดเมนของ URL นี้ไม่รวมอยู่ในโดเมนของแอพ”
ก่อนอื่นให้ฉันบอกว่าฉันเคยค้นหาคำตอบสำหรับคำถามนี้สักพัก ... ฉันกำลังพยายามตั้งค่า Facebook OAuth ให้ทำงานกับแอปพลิเคชันของฉันซึ่งได้รับการพัฒนาในเครื่องของฉัน ทุกอย่างทำงานได้สมบูรณ์แบบด้วยการอนุญาต Facebook จนถึงฉันเปลี่ยนจากการใช้localhostเป็นชื่อโดเมนอื่น (ยังอยู่ในเครื่องของฉัน) ตอนนี้ฉันได้รับข้อผิดพลาดต่อไปนี้ ไม่สามารถโหลด URL: โดเมนของ URL นี้ไม่รวมอยู่ในโดเมนของแอป เพื่อให้สามารถโหลด URL นี้เพิ่มโดเมนและโดเมนย่อยทั้งหมดของแอปของคุณไปยังฟิลด์ App Domains ในการตั้งค่าแอพของคุณ ไฟล์ hosts ของฉันมี127.0.0.1 photovote.dev (ทำงานได้สมบูรณ์) การเปลี่ยนเส้นทางของฉันในแอพของฉัน (ใช้ Socialite) คือ http://photovote.dev/auth/facebook/callback ในการตั้งค่า Facebook App ของฉัน ... โดเมนแอพของฉันคือ photovote.dev URL เว็บไซต์ของฉันคือ http://photovote.dev/ URIs การเปลี่ยนเส้นทาง OAuth ที่ถูกต้องของฉันคือ http://photovote.dev/auth/facebook/callback URL ณ เวลาที่ข้อความแสดงข้อผิดพลาดคือ …

6
ความปลอดภัยของโครงร่างการพิสูจน์ตัวตน REST
พื้นหลัง: ฉันออกแบบชุดรูปแบบการตรวจสอบสิทธิ์สำหรับเว็บเซอร์วิส REST สิ่งนี้ไม่จำเป็นต้อง "ปลอดภัย" จริง ๆ (เป็นโครงการส่วนตัวมากกว่า) แต่ฉันต้องการทำให้ปลอดภัยที่สุดเท่าที่จะเป็นได้จากการออกกำลังกาย / ประสบการณ์การเรียนรู้ ฉันไม่ต้องการใช้ SSL เนื่องจากฉันไม่ต้องการความยุ่งยากและค่าใช้จ่ายส่วนใหญ่ในการตั้งค่า คำถาม SO เหล่านี้มีประโยชน์อย่างยิ่งที่จะให้ฉันเริ่มต้น: รับรองความถูกต้องสงบ แนวทางปฏิบัติที่ดีที่สุดสำหรับการรักษาความปลอดภัย REST API / บริการบนเว็บ ตัวอย่าง SOAP / REST / RPC web API ที่ดีที่สุด? และทำไมคุณถึงชอบพวกเขา และมีอะไรผิดปกติกับพวกเขา? ฉันกำลังคิดที่จะใช้การรับรองความถูกต้องของAmazon S3แบบง่าย(ฉันชอบOAuthแต่ดูเหมือนซับซ้อนเกินไปสำหรับความต้องการของฉัน) ฉันกำลังเพิ่มnonce ที่สร้างแบบสุ่มซึ่งจัดหาโดยเซิร์ฟเวอร์ให้กับคำขอเพื่อป้องกันการโจมตีซ้ำ ในการรับคำถาม: ทั้ง S3 และ OAuth พึ่งพาการลงชื่อ URL คำขอพร้อมกับส่วนหัวที่เลือกไม่กี่รายการ ทั้งคู่ไม่ได้ลงนามในเนื้อความคำขอสำหรับคำขอ POST หรือ PUT …

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

9
OAuth คืออะไร (การอนุญาตเปิด)
OAuth คืออะไร (การอนุญาตเปิด) ฉันได้รวบรวมข้อมูลบางอย่างจาก OAuth Twitter Tutorial: OAuth คืออะไรและมันมีความหมายกับคุณอย่างไร OAuth คืออะไร แต่ฉันต้องการเรียนรู้และรู้เพิ่มเติม ฉันกำลังมองหาข้อมูลเกี่ยวกับวงจรชีวิต ทำไมเครือข่ายโซเชียลส่วนใหญ่จึงใช้โปรโตคอลเปิดนี้ มันจะกลายเป็นความจริงในอนาคตอันใกล้ด้วยเทคโนโลยีที่หลากหลาย (เช่น ASP.NET)?
201 oauth 

5
การสร้าง API สำหรับแอปพลิเคชันมือถือ - การรับรองความถูกต้องและการอนุญาต
ภาพรวม ฉันต้องการสร้าง API (REST) ​​สำหรับแอปพลิเคชันของฉัน วัตถุประสงค์เริ่มต้น / หลักจะใช้เพื่อการบริโภคโดยแอพมือถือ (iPhone, Android, Symbian และอื่น ๆ ) ฉันได้ดูกลไกที่แตกต่างกันสำหรับการรับรองความถูกต้องและการอนุญาตสำหรับ API บนเว็บ (โดยศึกษาการใช้งานอื่น ๆ ) ฉันมีหัวของฉันห่อหุ้มแนวคิดพื้นฐานส่วนใหญ่ แต่ฉันยังคงมองหาคำแนะนำในบางพื้นที่ สิ่งสุดท้ายที่ฉันต้องการทำคือสร้างวงล้อใหม่ แต่ฉันไม่พบวิธีแก้ปัญหามาตรฐานใด ๆ ที่เหมาะกับเกณฑ์ของฉัน (แต่เกณฑ์ของฉันถูกเข้าใจผิด นอกจากนี้ฉันต้องการให้ API เหมือนกันสำหรับทุกแพลตฟอร์ม / แอปพลิเคชันที่ใช้งาน oAuth ฉันจะไปข้างหน้าและคัดค้าน oAuth เนื่องจากฉันรู้ว่าน่าจะเป็นทางออกแรกที่เสนอ สำหรับแอปพลิเคชันมือถือ (หรือโดยเฉพาะที่ไม่ใช่เว็บแอปพลิเคชัน) ดูเหมือนว่าผิดที่จะออกจากแอปพลิเคชัน (ไปที่เว็บเบราว์เซอร์) สำหรับการตรวจสอบสิทธิ์ นอกจากนี้ไม่มีทาง (ฉันรู้) สำหรับเบราว์เซอร์ที่จะส่งกลับไปที่แอปพลิเคชัน (โดยเฉพาะข้ามแพลตฟอร์ม) ฉันรู้ว่ามีแอพสองตัวที่ทำเช่นนั้น แต่มันก็รู้สึกผิดและหยุดพักในแอปพลิเคชัน UX ความต้องการ ผู้ใช้ป้อนชื่อผู้ใช้ …

5
SSO ด้วย CAS หรือ OAuth?
ฉันสงสัยว่าฉันควรใช้โปรโตคอลCASหรือOAuth + ผู้ให้บริการการพิสูจน์ตัวตนบางรายสำหรับการลงชื่อเข้าใช้ครั้งเดียวหรือไม่ ตัวอย่างสถานการณ์: ผู้ใช้พยายามเข้าถึงทรัพยากรที่มีการป้องกัน แต่ไม่ได้รับการรับรองความถูกต้อง แอปพลิเคชันเปลี่ยนเส้นทางผู้ใช้ไปยังเซิร์ฟเวอร์ SSO หากการผึ้งรับรองความถูกต้องผู้ใช้จะได้รับโทเค็นจากเซิร์ฟเวอร์ SSO SSO เปลี่ยนเส้นทางไปยังแอปพลิเคชันดั้งเดิม แอปพลิเคชันดั้งเดิมตรวจสอบโทเค็นกับเซิร์ฟเวอร์ SSO หากโทเค็นตกลงการเข้าถึงจะได้รับอนุญาตและแอปพลิเคชันจะรู้รหัสผู้ใช้ ผู้ใช้ทำการล็อกเอาต์และออกจากแอพพลิเคชั่นที่เชื่อมต่อทั้งหมดพร้อมกัน (การลงชื่อออกครั้งเดียว) เท่าที่ฉันเข้าใจว่าเป็นสิ่งที่ CAS คิดค้นขึ้นมา ลูกค้า CAS ต้องใช้โปรโตคอล CAS เพื่อใช้บริการตรวจสอบความถูกต้อง ตอนนี้ฉันสงสัยว่าจะใช้ CAS หรือ OAuth ที่ไซต์ลูกค้า (ผู้บริโภค) OAuth เป็นส่วนทดแทนสำหรับ CAS นั้นหรือไม่ OAuth ในฐานะมาตรฐานความเป็นจริงใหม่ควรเป็นที่ต้องการหรือไม่ มีการใช้งานง่าย (ไม่ใช่ Sun OpenSSO!) แทนส่วนการรับรองความถูกต้องของ CAS ที่รองรับวิธีการที่แตกต่างกันเช่นชื่อผู้ใช้ / รหัสผ่าน OpenID ใบรับรอง TLS ... …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.