ใน OpenID Connect โทเค็นการเข้าถึงมีเวลาหมดอายุ สำหรับโฟลว์รหัสการอนุญาตโดยทั่วไปจะสั้น (เช่น 20 นาที) หลังจากนั้นคุณใช้โทเค็นการรีเฟรชเพื่อขอโทเค็นการเข้าถึงใหม่

ID tokenนอกจากนี้ยังมีเวลาหมดอายุ คำถามของฉันคือเจตนาของสิ่งนี้คืออะไร?

เวลาหมดอายุของโทเค็น ID ใด ๆ น้อยกว่าเวลาหมดอายุของโทเค็นการรีเฟรชจะหมายความว่าในที่สุดคุณจะมีโทเค็น ID ที่หมดอายุ แต่โทเค็นการเข้าถึงที่ถูกต้อง

คุณตั้งใจที่จะ:

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

ข้อกำหนดOpenID Connectบอกว่าเมื่อตรวจสอบความถูกต้องของโทเค็น ID

"The current time MUST be before the time represented by the exp Claim."

ซึ่ง (อาจ) รองรับตัวเลือกที่สามด้านบน

แก้ไข

เนื่องจาก OpenID Connect สร้างบน OAuth2 คำตอบสำหรับคำถามเสริมด้านล่างสามารถพบได้ในข้อกำหนด OAuth2ซึ่งกล่าวว่า

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

คำถามที่เกี่ยวข้องคือเมื่อคุณแลกเปลี่ยนรหัสการอนุญาตสำหรับโทเค็นข้อกำหนดเดียวกันระบุว่าคุณอาจได้รับคำตอบเช่น:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

แต่ "expires_in" เกี่ยวข้องกับอะไรในกรณีนี้ โทเค็นการเข้าถึงโทเค็นการรีเฟรชหรือโทเค็น ID?

(สำหรับข้อมูลIdentityServer3ตั้งค่านี้เป็นเวลาหมดอายุโทเค็นการเข้าถึง)

ฉันกำลังตอบคำถามของตัวเองเนื่องจากพบว่าสมมติฐานบางอย่างที่อยู่เบื้องหลังคำถามของฉันผิดดังนั้นจึงง่ายต่อการชี้แจงที่นี่แทนที่จะเขียนคำถามซ้ำ

โทเค็น ID มีไว้เพื่อพิสูจน์ให้ลูกค้าทราบว่าผู้ใช้ได้พิสูจน์ตัวตนแล้วและผลที่ตามมาคือใคร

เมื่อลูกค้าได้รับโทเค็น ID โดยทั่วไปจะทำบางอย่างเช่นแปลงเป็น ClaimsIdentity และคงอยู่เช่นการใช้คุกกี้

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

สมมติฐานที่ผิดของฉันเมื่อถามคำถามคือควรใช้โทเค็น ID และโทเค็นการเข้าถึงร่วมกันดังนั้นทั้งคู่จึงจำเป็นต้องมีวันหมดอายุที่ถูกต้อง สิ่งนี้ผิดจากหลายสาเหตุ:

• ID โทเค็นใช้สำหรับการพิสูจน์ตัวตนกับลูกค้าเท่านั้น (ตามที่อธิบายไว้ข้างต้น)
• โทเค็นการเข้าถึงไม่มีส่วนเกี่ยวข้องกับไคลเอนต์ มีไว้สำหรับการเข้าถึงทรัพยากรและลูกค้าจะจัดการเฉพาะในกรณีที่จำเป็นต้องเรียกทรัพยากร
• สิ่งที่ต้องการแบบสแตนด์อโลน MVC หรือ WebForms แอพลิเคชันเพียงต้องการโทเค็นรหัส หากไม่ได้เรียกใช้ทรัพยากรภายนอกจะไม่มีสิ่งใดให้สิทธิ์เข้าถึงดังนั้นจึงไม่มีโทเค็นการเข้าถึง

ฉันต้องเจาะลึกเรื่องนี้ด้วยเหตุผลของตัวเองและเขียนมันขึ้นมาดังนั้นฉันจะโพสต์สิ่งที่ได้เรียนรู้ที่นี่ ...

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

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

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

สำหรับโฟลว์โดยนัยใน OIDC / OAuthคุณขอ ID Token ที่จุดสิ้นสุดการอนุญาตโดยเปลี่ยนเส้นทางผู้ใช้ในเบราว์เซอร์ไปยังจุดสิ้นสุดการอนุญาตและรวมid_tokenเป็นค่าของresponse_typeพารามิเตอร์คำขอ การตอบสนองการพิสูจน์ตัวตนที่ประสบความสำเร็จของโฟลวโดยนัยจำเป็นต้องรวมไฟล์id_token.

สำหรับโฟลว์ Authentication Codeไคลเอ็นต์ระบุcodeเป็นค่าของresponse_typeพารามิเตอร์คำร้องขอเมื่อเปลี่ยนทิศทางผู้ใช้ไปยังจุดสิ้นสุดการอนุญาต การตอบสนองที่ประสบความสำเร็จประกอบด้วยรหัสการอนุญาต ลูกค้าลูกค้าที่ทำให้การร้องขอไปยังปลายทางโทเค็นกับรหัสอนุมัติและตามOIDC หลักมาตรา 3.1.3.3 ที่ประสบความสำเร็จ Token ตอบสนอง การตอบสนองจะต้องมีรหัส Token

ดังนั้นสำหรับทั้งสองขั้นตอนนั่นเป็นวิธีที่คุณได้รับ ID Token ในตอนแรก แต่คุณจะรีเฟรชได้อย่างไร? OIDC ส่วนที่ 12: การใช้โทเค็นการรีเฟรชมีคำสั่งต่อไปนี้เกี่ยวกับการตอบสนองการรีเฟรชโทเค็น:

เมื่อตรวจสอบความสำเร็จในการรีเฟรช Token ร่างกายตอบสนองเป็น Token ตอบสนองของมาตรา 3.1.3.3 ยกเว้นว่ามันอาจจะไม่ประกอบด้วย id_token

มันอาจจะไม่มีรหัส Token และตั้งแต่มีวิธีใดที่ระบุบังคับให้รวมถึงโทเค็น ID คุณต้องคิดว่าการตอบสนองจะไม่ประกอบด้วยรหัส Token ดังนั้นในทางเทคนิคจึงไม่มีวิธีที่ระบุในการ "รีเฟรช" ID Token โดยใช้โทเค็นการรีเฟรช ดังนั้นวิธีเดียวที่จะได้รับ ID Token ใหม่คือการให้สิทธิ์ / พิสูจน์ตัวตนผู้ใช้อีกครั้งโดยเปลี่ยนเส้นทางผู้ใช้ไปยังจุดสิ้นสุดการให้สิทธิ์และเริ่มขั้นตอนโดยนัยหรือโฟลว์รหัสการพิสูจน์ตัวตนตามที่อธิบายไว้ข้างต้น ข้อกำหนด OIDC จะเพิ่มpromptพารามิเตอร์การร้องขอไปยังคำขอการอนุญาตเพื่อให้ไคลเอ็นต์สามารถร้องขอให้เซิร์ฟเวอร์การอนุญาตไม่พร้อมท์ผู้ใช้ด้วย UI ใด ๆ แต่การเปลี่ยนเส้นทางยังคงต้องเกิดขึ้น

หากฉันเข้าใจถูกต้องตามนี้และข้อมูลจำเพาะ OpenID Connect Core 1.0โทเค็น ID เองสามารถถูกเก็บไว้ในคุกกี้เพื่อเป็นกลไกในการคงอยู่ของเซสชันและส่งไปพร้อมกับคำขอที่ต้องมีการตรวจสอบความถูกต้องทั้งหมดไปยังไคลเอนต์ จากนั้นลูกค้าสามารถยืนยันโทเค็น ID ได้ทั้งภายในเครื่องหรือผ่านจุดสิ้นสุดของผู้ยืนยันของผู้ให้บริการ (หากมีให้เช่นเดียวกับ Google ) หากโทเค็นหมดอายุควรทำการร้องขอการตรวจสอบสิทธิ์อีกครั้งยกเว้นในครั้งนี้ด้วยprompt=noneในพารามิเตอร์ URL และอย่าลืมส่งโทเค็น ID ที่หมดอายุในid_token_hintพารามิเตอร์มิฉะนั้นผู้ให้บริการอาจส่งคืนข้อผิดพลาด

ดังนั้นจึงดูเหมือนเป็นเรื่องปกติที่ ID Token จะหมดอายุ แต่prompt=noneมั่นใจได้ว่าจะได้รับโทเค็น ID ใหม่อย่างราบรื่นโดยไม่มีการแทรกแซงของผู้ใช้ (เว้นแต่ผู้ใช้จะออกจากระบบ OpenID นั้น)

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

ผู้บริโภคid_tokenจะต้องตรวจสอบความถูกต้อง (เวลา) ของมันเสมอ

ฉันไม่คุ้นเคยกับ IS 100% แต่ฉันเดาว่ามันเป็นช่องอำนวยความสะดวก คุณควรตรวจสอบการexpอ้างสิทธิ์อยู่เสมอ

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

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

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

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

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

• id_token สำหรับการตรวจสอบสิทธิ์ - ซึ่งไม่ควรใช้อีกในการเรียกเซิร์ฟเวอร์ยกเว้นเป็นคำใบ้ในระหว่างการออกจากระบบเมื่อการหมดอายุไม่สำคัญอีกต่อไปดังนั้นด้วยเหตุผลข้างต้นควรปล่อยให้หมดอายุและห้ามรีเฟรช
• access_token ซึ่งในภายหลังเมื่อเรียก API สามารถกำหนดให้กับปลายทาง UserInfo ของ OP ได้ ซึ่งจะส่งคืนการอ้างสิทธิ์และ API สามารถให้สิทธิ์ตามนั้น

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

ฉันต้องการโพสต์คำตอบนี้เป็นความคิดเห็น แต่เนื่องจากฉันไม่ได้ใช้งาน StackOverflow มากนักฉันเดาว่าฉันกำลังโพสต์เป็นคำตอบอื่น

นอกจากนี้คุณยังใช้id_tokenเป็นid_token_hintเมื่อพยายามที่จะเข้าสู่ระบบของผู้ใช้ออกจากเซสชั่นhttp://openid.net/specs/openid-connect-session-1_0.html ฉันไม่คิดว่ามันสำคัญจริงๆหากid_tokenหมดอายุในตอนนี้เนื่องจากคุณกังวลเกี่ยวกับการออกจากระบบผู้ใช้บางรายเท่านั้น

TLDR;

ตรวจสอบความถูกต้องของโทเค็น ID ก่อนที่จะเชื่อถือสิ่งที่ระบุ

รายละเอียดเพิ่มเติม

เจตนาของเวลาหมดอายุของโทเค็น ID ใน OpenID Connect คืออะไร

เจตนาคือการช่วยให้ลูกค้าในการตรวจสอบโทเค็น ID และลูกค้าจะต้องตรวจสอบหมายเลขโทเค็นก่อนที่จะดำเนินการที่ใช้ข้อมูลโทเค็นรหัสของ

จากข้อกำหนด OpenID Implicit Flow :

หากขั้นตอนการตรวจสอบความถูกต้องที่กำหนดไว้ในเอกสารนี้ล้มเหลวการดำเนินการใด ๆ ที่ต้องใช้ข้อมูลที่ไม่สามารถตรวจสอบความถูกต้องได้อย่างถูกต้องจะต้องถูกยกเลิกและข้อมูลที่ไม่สามารถตรวจสอบความถูกต้องจะต้องไม่ถูกนำมาใช้

เพื่อยืนยันสิ่งนั้นเอกสาร OpenID Connect ของ Googleกล่าวเกี่ยวกับการตรวจสอบ ID โทเค็น:

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

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