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

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

604 oauth  oauth-2.0  authorization 

ตามที่ผมเข้าใจมันห่วงโซ่ต่อไปของเหตุการณ์ที่เกิดขึ้นใน OAuth 2 เพื่อให้Site-Aเข้าถึงผู้ใช้Site-Bข้อมูลจาก Site-AลงทะเบียนSite-Bและรับ Secret และ ID เมื่อผู้ใช้บอกSite-Aต่อการเข้าถึงSite-B, ผู้ใช้จะถูกส่งไปSite-Bที่พวกเขาบอกSite-Bว่าพวกเขาจะแน่นอนชอบที่จะให้Site-Aสิทธิ์กับข้อมูลที่เฉพาะเจาะจง Site-Bเปลี่ยนเส้นทางผู้ใช้กลับไปที่Site-Aพร้อมกับรหัสการอนุญาต Site-Aจากนั้นส่งรหัสการอนุญาตพร้อมกับความลับของมันกลับไปเพื่อSite-Bตอบแทนโทเค็นความปลอดภัย Site-Aจากนั้นทำการร้องขอSite-Bในนามของผู้ใช้โดยการรวมโทเค็นความปลอดภัยพร้อมกับคำขอ ทั้งหมดนี้ทำงานอย่างไรในแง่ของความปลอดภัยและการเข้ารหัสในระดับสูง? OAuth 2 ป้องกันสิ่งต่าง ๆ เช่นการโจมตีเล่นซ้ำโดยใช้โทเค็นความปลอดภัยได้อย่างไร

564 oauth-2.0 

บนเว็บไซต์https://code.google.com/apis/consoleฉันได้ลงทะเบียนแอปพลิเคชันของฉันแล้วตั้งค่ารหัสลูกค้าที่สร้าง:และความลับลูกค้าในแอปของฉันและพยายามลงชื่อเข้าใช้ด้วย Google น่าเสียดายที่ฉันได้รับข้อความแสดงข้อผิดพลาด: Error: redirect_uri_mismatch The redirect URI in the request: http://127.0.0.1:3000/auth/google_oauth2/callback did not match a registered redirect URI scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email response_type=code redirect_uri=http://127.0.0.1:3000/auth/google_oauth2/callback access_type=offline approval_prompt=force client_id=generated_id ข้อความนี้หมายถึงอะไรและฉันจะแก้ไขได้อย่างไร ผมใช้อัญมณีomniauth-google-OAuth2

386 authentication  oauth-2.0  google-signin 

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

264 authentication  oauth  oauth-2.0 

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

256 oauth  oauth-2.0 

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

254 oauth  user-agent  oauth-2.0 

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

209 oauth  oauth-2.0  google-api  google-oauth 

โปรแกรมเมอร์ผู้เริ่มต้นที่นี่โปรดอภัยความไม่รู้และคำอธิบายจะดีจริงๆ :) ฉันพยายามอ่านบทแนะนำสำหรับบริการ OAuth 2.0 บางอย่าง แต่ฉันไม่เข้าใจ URI การเปลี่ยนเส้นทางนี้ ... ในบริบทเฉพาะของฉันสมมติว่าฉันกำลังพยายามสร้างแอป iPhone ที่ใช้ OAuth 2.0 สำหรับบริการบางอย่าง . ฉันมีรหัสแอปที่สร้างขึ้น แต่ฉันต้องจัดเตรียม URI การเปลี่ยนเส้นทางบางอย่างเพื่อสร้างคีย์ API นี่เป็น URL ที่ฉันควรจะโฮสต์ด้วยตัวเองหรือไม่? ตามชื่อที่แนะนำฉันคิดว่า URL การเปลี่ยนเส้นทางควรจะ "เปลี่ยนเส้นทาง" บางคน ฉันเดาเพียงว่ามันเป็น URL ที่ผู้ใช้ถูกเปลี่ยนเส้นทางไปหลังจากพวกเขาเข้าสู่บริการ อย่างไรก็ตามแม้ว่าข้อสันนิษฐานนั้นจะถูกต้อง แต่ฉันไม่เข้าใจสิ่งอื่น - แอพของฉันจะเปิดอีกครั้งได้อย่างไรหลังจากที่ฉันส่งพวกเขาไปยังเบราว์เซอร์สำหรับการเข้าสู่ระบบของผู้ใช้

184 ios  authentication  uri  oauth-2.0 

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

165 oauth  oauth-2.0 

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

157 android  oauth-2.0  retrofit 

ฉันพยายามลงทะเบียนแอพ android ของฉันโดยทำตามขั้นตอนใน https://developers.google.com/console/help/#installed_applicationsซึ่งทำให้ฉันทำตาม http://developer.android.com/tools/publishing/app- เซ็นต์ . html อย่างไรก็ตามฉันไม่แน่ใจว่าจะได้รับลายนิ้วมือใบรับรองการลงนาม (SHA1) ได้อย่างไร ฉันแรกใช้ปลั๊กอิน Eclipse ADT เพื่อส่งออกและสร้างที่เก็บคีย์ / คีย์ จากนั้นฉันลองทำkeytool -list keystore mykeystore.keystoreและให้ลายนิ้วมือ MD5 Certificate กับฉัน ฉันต้องทำซ้ำการลงชื่ออีกครั้ง (หมายถึงฉันไม่สามารถใช้ตัวช่วยสร้างการส่งออก eclipse ได้)? ฉันสามารถใช้ใบรับรองการดีบักก่อนได้หรือไม่

154 android  oauth-2.0 

เมื่อฉันได้รับaccess_tokenจาก Google API มันมาพร้อมกับexpires_inค่า ตามเอกสารประกอบค่านี้ระบุ "อายุการใช้งานที่เหลืออยู่ของโทเค็นการเข้าถึง" หน่วยของค่านี้คืออะไร?

150 oauth-2.0 

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

147 oauth  oauth-2.0 

ฉันกำลังพยายามใช้fetchใน React Native เพื่อดึงข้อมูลจาก Product Hunt API ฉันได้รับโทเค็นการเข้าถึงที่เหมาะสมและบันทึกไว้ในสถานะแล้ว แต่ดูเหมือนจะไม่สามารถส่งต่อได้ภายในส่วนหัวการให้สิทธิ์สำหรับคำขอ GET นี่คือสิ่งที่ฉันมี: var Products = React.createClass({ getInitialState: function() { return { clientToken: false, loaded: false } }, componentWillMount: function () { fetch(api.token.link, api.token.object) .then((response) => response.json()) .then((responseData) => { console.log(responseData); this.setState({ clientToken: responseData.access_token, }); }) .then(() => { this.getPosts(); }) .done(); …

141 javascript  oauth-2.0  react-native  fetch-api 

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

140 oauth-2.0