วิธีการตรวจสอบโทเค็นการเข้าถึง OAuth 2.0 สำหรับเซิร์ฟเวอร์ทรัพยากร

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

ปรับปรุงพฤศจิกายน 2015:เป็นต่อฮันส์ซีด้านล่าง - นี่คือตอนที่กำหนดไว้แน่นอนเป็นส่วนหนึ่งของRFC 7662

คำตอบเดิม:ข้อมูลจำเพาะ OAuth 2.0 ( RFC 6749 ) ไม่ได้ระบุการโต้ตอบอย่างชัดเจนระหว่าง Resource Server (RS) และเซิร์ฟเวอร์การอนุญาต (AS) สำหรับการตรวจสอบการเข้าถึงโทเค็น (AT) มันขึ้นอยู่กับรูปแบบ / กลยุทธ์โทเค็นของ AS - โทเค็นบางอย่างมีอยู่ในตัวเอง (เช่นJSON Web Tokens ) ในขณะที่คนอื่น ๆ อาจคล้ายกับคุกกี้เซสชันในการที่พวกเขาเพียงแค่อ้างอิงข้อมูลด้านเซิร์ฟเวอร์ที่ AS

มีการพูดคุยกันในคณะทำงาน OAuth เกี่ยวกับการสร้างวิธีมาตรฐานสำหรับ RS เพื่อสื่อสารกับการตรวจสอบ AS สำหรับ AT บริษัท ของฉัน (ปิอัตลักษณ์) ได้เกิดขึ้นกับหนึ่งในวิธีการดังกล่าวเพื่อการพาณิชย์ OAuth ของเราเป็น (PingFederate): https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001 ใช้การโต้ตอบที่ใช้ REST สำหรับสิ่งนี้ซึ่งเป็นส่วนเสริมของ OAuth 2.0

วิธีของ Google

การตรวจสอบโทเค็นของ Google Oauth2

คำขอ:

https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg

การตอบสนอง:

{
  "audience":"8819981768.apps.googleusercontent.com",
  "user_id":"123456789",
  "scope":"https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "expires_in":436
} 

วิธีของ Microsoft

Microsoft - Oauth2 ตรวจสอบการอนุญาต

วิธี GitHub

Github - Oauth2 ตรวจสอบการอนุญาต

คำขอ:

GET /applications/:client_id/tokens/:access_token

การตอบสนอง:

{
  "id": 1,
  "url": "https://api.github.com/authorizations/1",
  "scopes": [
    "public_repo"
  ],
  "token": "abc123",
  "app": {
    "url": "http://my-github-app.com",
    "name": "my github app",
    "client_id": "abcde12345fghij67890"
  },
  "note": "optional note",
  "note_url": "http://optional/note/url",
  "updated_at": "2011-09-06T20:39:23Z",
  "created_at": "2011-09-06T17:26:27Z",
  "user": {
    "login": "octocat",
    "id": 1,
    "avatar_url": "https://github.com/images/error/octocat_happy.gif",
    "gravatar_id": "somehexcode",
    "url": "https://api.github.com/users/octocat"
  }
}

ทางอเมซอน

เข้าสู่ระบบด้วย Amazon - คู่มือผู้พัฒนา (ธันวาคม 2015, หน้า 21)

ขอ:

https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR...

คำตอบ:

HTTP/l.l 200 OK
Date: Fri, 3l May 20l3 23:22:l0 GMT 
x-amzn-RequestId: eb5be423-ca48-lle2-84ad-5775f45l4b09 
Content-Type: application/json 
Content-Length: 247 

{ 
  "iss":"https://www.amazon.com", 
  "user_id": "amznl.account.K2LI23KL2LK2", 
  "aud": "amznl.oa2-client.ASFWDFBRN", 
  "app_id": "amznl.application.436457DFHDH", 
  "exp": 3597, 
  "iat": l3ll280970
}

การปรับปรุงเกี่ยวกับคำตอบของ @Scott ตัน: อินเตอร์เฟซระหว่างทรัพยากรของเซิร์ฟเวอร์และการอนุญาตเซิร์ฟเวอร์สำหรับการตรวจสอบโทเค็นเป็นมาตรฐานใน IETF RFC 7662 ในเดือนตุลาคมปี 2015 ดู: https://tools.ietf.org/html/rfc7662 ตัวอย่างการตรวจสอบความถูกต้องจะมีลักษณะดังนี้:

POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483

token=2YotnFZFEjr1zCsicMWpAA

และการตอบสนองตัวอย่าง:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "client_id": "l238j323ds-23ij4",
  "username": "jdoe",
  "scope": "read write dolphin",
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource",
  "iss": "https://server.example.com/",
  "exp": 1419356238,
  "iat": 1419350238,
  "extension_field": "twenty-seven"
}

แน่นอนว่าการยอมรับโดยผู้ขายและผลิตภัณฑ์จะต้องเกิดขึ้นเมื่อเวลาผ่านไป

ข้อมูลจำเพาะ OAuth 2.0 ไม่ได้กำหนดชิ้นส่วนไว้ แต่อาจมีสองตัวเลือก:

1. เมื่อเซิร์ฟเวอร์ทรัพยากรได้รับโทเค็นใน Authz Header ดังนั้นจะเรียกใช้ validate / introspect API บนเซิร์ฟเวอร์ Authz เพื่อตรวจสอบโทเค็น ที่นี่เซิร์ฟเวอร์ Authz อาจตรวจสอบได้ไม่ว่าจะจากการใช้ DB Store หรือตรวจสอบลายเซ็นและคุณลักษณะบางอย่าง เป็นส่วนหนึ่งของการตอบสนองมันจะถอดรหัสโทเค็นและส่งข้อมูลจริงของโทเค็นพร้อมกับเวลาหมดอายุที่เหลืออยู่

2. เซิร์ฟเวอร์ Authz สามารถเข้ารหัส / เซ็นโทเค็นโดยใช้คีย์ส่วนตัวจากนั้น publickey / cert สามารถมอบให้กับ Resource Server เมื่อเซิร์ฟเวอร์ทรัพยากรได้รับโทเค็นมันจะถอดรหัส / ตรวจสอบลายเซ็นเพื่อตรวจสอบโทเค็น นำเนื้อหาออกและประมวลผลโทเค็น จากนั้นสามารถให้การเข้าถึงหรือปฏิเสธ

ข้อกำหนดของ OAuth v2 บ่งชี้:

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

เซิร์ฟเวอร์การอนุญาตของฉันมีจุดปลาย webservice (SOAP) ที่อนุญาตให้เซิร์ฟเวอร์ทรัพยากรทราบว่า access_token นั้นถูกต้องหรือไม่