OAuth 2.0 เป็นข้อตกลงการออกใบอนุญาตเกรดอุตสาหกรรม OAUTH 2.0 ได้รับการสืบทอดมาจาก OAuth 1.0 ซึ่งสร้างขึ้นในปี 2549 OAuth 2.0 มุ่งมั่นที่จะช่วยให้นักพัฒนาได้รับอนุญาตง่ายขึ้นและให้กระบวนการอนุญาตเฉพาะสำหรับเว็บแอปพลิเคชันแอปพลิเคชันเดสก์ท็อปแอปพลิเคชันมือถือและแอปพลิเคชันแบบฝังตัว
OAuth 2.0 เป็นโปรโตคอลมาตรฐานอุตสาหกรรมสำหรับการอนุญาต OAuth 2.0 แทนที่งานที่ทำในโปรโตคอล OAuth ดั้งเดิมที่สร้างขึ้นในปี 2549 OAuth 2.0 มุ่งเน้นไปที่ความเรียบง่ายของนักพัฒนาลูกค้าในขณะที่ให้การอนุญาตการอนุญาตเฉพาะสำหรับเว็บแอปพลิเคชัน, แอปพลิเคชันเดสก์ท็อป, โทรศัพท์มือถือและอุปกรณ์ห้องนั่งเล่น
สี่อักขระของ OAuth 2.0
เพื่อความเข้าใจที่ง่ายให้ใช้การเข้าสู่ระบบ WeChat ที่ใช้กันทั่วไปเป็นตัวอย่าง
เจ้าของทรัพยากร
เจ้าของทรัพยากรข้อมูลส่วนบุคคลที่ตั้งอยู่บน WeChat โดยผู้ใช้แต่ละคนที่สอดคล้องกับ WeChat เป็นของผู้ใช้แต่ละคนและไม่ได้เป็นของ Tencent
เซิร์ฟเวอร์ทรัพยากร
โดยทั่วไปแล้วเซิร์ฟเวอร์ทรัพยากรจะเป็น REST APIs สำหรับการดำเนินการบางอย่างของข้อมูลผู้ใช้ (การเพิ่มการลบการปรับเปลี่ยนและการค้นหา) เช่นอินเทอร์เฟซของ WeChat เพื่อรับข้อมูลพื้นฐานของผู้ใช้
แอปพลิเคชันไคลเอนต์
ลูกค้าบุคคลที่สามเมื่อเทียบกับแอปพลิเคชันที่พัฒนาโดยบัญชีสาธารณะ WeChat ต่างๆแอปพลิเคชันของบุคคลที่สามสามารถเข้าถึง REST API ของเซิร์ฟเวอร์ทรัพยากรหลังจากได้รับอนุญาตจากเซิร์ฟเวอร์การตรวจสอบสิทธิ์เพื่อรับข้อมูลพื้นฐานเช่นอวตารของผู้ใช้เพศภูมิภาค ฯลฯ
เซิร์ฟเวอร์การอนุญาต
รับรองความถูกต้องเซิร์ฟเวอร์เพื่อตรวจสอบว่าไคลเอนต์บุคคลที่สามนั้นถูกกฎหมายหรือไม่ หากถูกกฎหมายให้ออกโทเค็นให้กับลูกค้าและบุคคลที่สามใช้โทเค็นเพื่อเรียก API ของเซิร์ฟเวอร์ทรัพยากร
วิธีการอนุญาตสี่วิธี (ประเภทแกรนท์)
anthorization_code
ประเภทรหัสการอนุญาตใช้งานได้กับแอปพลิเคชันเว็บเซิร์ฟเวอร์ โหมดคือ: ไคลเอ็นต์การโทรครั้งแรก/OAUTH/อนุญาต/เพื่อป้อนอินเทอร์เฟซการอนุญาตของผู้ใช้และส่งคืนรหัสหลังจากการอนุญาตของผู้ใช้และจากนั้นไคลเอนต์จะได้รับโทเค็นการเข้าถึงตามรหัสและ AppSecret
โดยนัยง่ายขึ้นประเภท และมีขั้นตอนน้อยกว่าในการรับรหัสการอนุญาตมากกว่าประเภทรหัสการอนุญาต หลังจากที่แอปพลิเคชันไคลเอนต์ได้รับอนุญาตเซิร์ฟเวอร์การตรวจสอบความถูกต้องจะวางโทเค็นการเข้าถึงโดยตรงบน URL ของไคลเอนต์ ลูกค้าวิเคราะห์ URL เพื่อรับโทเค็น วิธีนี้ไม่ปลอดภัยมากและคุณสามารถใช้ช่องทาง HTTPS ที่ปลอดภัยและลดเวลาการเข้าถึงโทเค็นเพื่อลดความเสี่ยง
รหัสผ่าน
ประเภทรหัสผ่านแอปพลิเคชันไคลเอนต์จะได้รับโทเค็นผ่านชื่อผู้ใช้และรหัสผ่าน เหมาะสำหรับเซิร์ฟเวอร์ทรัพยากรเซิร์ฟเวอร์การตรวจสอบและลูกค้ามีความสัมพันธ์ที่เชื่อถือได้อย่างสมบูรณ์เนื่องจากผู้ใช้ต้องการส่งชื่อผู้ใช้และรหัสผ่านของผู้ใช้โดยตรงไปยังแอปพลิเคชันไคลเอนต์ แอปพลิเคชันไคลเอนต์ได้รับโทเค็นผ่านชื่อผู้ใช้และรหัสผ่านที่ส่งโดยผู้ใช้จากนั้นเข้าถึงทรัพยากรเซิร์ฟเวอร์ทรัพยากร ตัวอย่างเช่น Alipay สามารถเข้าสู่ระบบโดยตรงกับชื่อผู้ใช้และรหัสผ่าน Taobao เพราะพวกเขาอยู่ใน บริษัท เดียวกันและพวกเขาไว้วางใจซึ่งกันและกันอย่างเต็มที่
client_credentials
ประเภทไคลเอนต์เป็นวิธีที่ไม่ต้องการการมีส่วนร่วมของผู้ใช้และใช้สำหรับการเชื่อมต่อระหว่างบริการที่แตกต่างกัน ตัวอย่างเช่นแอปพลิเคชันที่คุณพัฒนาเองจำเป็นต้องโทรติดต่อบริการของผู้ให้บริการรหัสตรวจสอบ SMS โทรติดต่อบริการของผู้ให้บริการแผนที่และโทรหาบริการของผู้ให้บริการส่งข้อความโทรศัพท์มือถือ เมื่อคุณต้องการโทรหาบริการคุณสามารถใช้ ID แอพและแอพเซรทโดยตรงที่ผู้ให้บริการให้ไว้เพื่อรับโทเค็น หลังจากที่คุณได้รับโทเค็นคุณสามารถโทรหาบริการโดยตรง
แนวคิดอื่น ๆ
ทำให้สำเร็จ
บางครั้งเซิร์ฟเวอร์ทรัพยากรและเซิร์ฟเวอร์การตรวจสอบความถูกต้องเป็นแอปพลิเคชั่นที่แตกต่างกันสองรายการ บางครั้งเซิร์ฟเวอร์ทรัพยากรและเซิร์ฟเวอร์การรับรองความถูกต้องอยู่ในแอปพลิเคชันเดียวกัน ความแตกต่างคือว่าเซิร์ฟเวอร์ทรัพยากรจำเป็นต้องตรวจสอบความถูกต้องของโทเค็นหรือไม่ อดีตจำเป็นต้องตรวจสอบในขณะที่หลังไม่ได้ หลังถูกนำไปใช้ที่นี่
การกำหนดค่าความปลอดภัยของแอปพลิเคชัน
@ConfigurationPublic คลาส SecurityConfiguration ขยาย WebSecurityConfigurerAdapter {@Override Void Protected Void Configure (httpsecurity http) โยนข้อยกเว้น {http.formlogin () .and (). csrf (); } @Override โมฆะสาธารณะกำหนดค่า (WebSecurity Web) โยนข้อยกเว้น {super.configure (เว็บ); } @Override Void Protected Configure (AuthenticationManagerBuilder Auth) โยนข้อยกเว้น {auth.inmemoryauthentication (). withuser ("lyt"). รหัสผ่าน ("lyt"). เจ้าหน้าที่ ("role_user") และ () } @Bean @Override AuthenticationManager AuthenticationManagerBean () โยนข้อยกเว้น {return super.authenticationManagerBean (); -การกำหนดค่าเซิร์ฟเวอร์การรับรองความถูกต้อง
@enableauthorizationserver @configurationPublic การอนุญาตคลาสการกำหนดค่าการกำหนดค่าการอนุญาตให้ใช้งานการกำหนดค่าใช้จ่าย {@Override public void กำหนดค่า (clientDetailsServiceConfigurer ลูกค้า .AuterizedGrantTypes ("Authorization_Code", "รหัสผ่าน", "โดยนัย", "client_credentials");} @Override โมฆะสาธารณะการกำหนดค่า (AuthorizationServersecurityCurity } @Override โมฆะสาธารณะการกำหนดค่า (การอนุญาตให้ใช้งานจุดสิ้นสุดจุดสิ้นสุด) พ่นข้อยกเว้น {endpoints.authenticationManager (AuthenticationManager); } @autowired @qualifier ("AuthenticationManagerBean") AuthenticationManager Private AuthenticationManager;}การกำหนดค่าเซิร์ฟเวอร์ทรัพยากร
@enableGlobalMethodSecurity (prepOntenabled = true)@enableResourceserver@configurationPublic คลาสทรัพยากรการกำหนดค่าการกำหนดค่าใช้งานขยาย ResourcesERverConfigurerAdapter {@Override โมฆะสาธารณะกำหนดค่า (httpsecurity http) .AntMatchers (httpmethod.get, "/read/**" ).access("#oauth2.hasscope('read ')") .AntMatchers (httpmethod.post, "/write/**) -การตั้งค่าการสั่งซื้อตัวกรองเซิร์ฟเวอร์ทรัพยากร
คุณต้องตั้งค่าการสั่งซื้อตัวกรองเป็น 3 ใน application.yml โปรดดูลิงค์ด้วยเหตุผลเฉพาะ
ป้องกันความขัดแย้งของคุกกี้
เพื่อหลีกเลี่ยงข้อผิดพลาดระหว่างคุกกี้ของเซิร์ฟเวอร์การรับรองความถูกต้องและคุกกี้ระหว่างไคลเอนต์และคุกกี้ควรปรับเปลี่ยนชื่อคุกกี้หรือตั้งค่าบริบท
ทดสอบ
Postman ให้วิธีการตรวจสอบความถูกต้อง OAuth 2.0 คุณสามารถรับโทเค็นและเพิ่มการรับรองความถูกต้องในคำขอ HTTP จากนั้นขอ REST API ของเซิร์ฟเวอร์ทรัพยากร
ข้อมูลลูกค้า
การอนุญาต
โทเค็นที่ได้รับ
การเข้าถึง API เซิร์ฟเวอร์ทรัพยากร
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ของทุกคนและฉันหวังว่าทุกคนจะสนับสนุน wulin.com มากขึ้น