Bagaimana cara memvalidasi token akses OAuth 2.0 untuk server sumber daya?

Ketika klien meminta server sumber daya untuk mendapatkan sumber daya yang dilindungi dengan token akses OAuth 2.0, bagaimana server ini memvalidasi token? Protokol token penyegaran OAuth 2.0?

Pembaruan November 2015: Sesuai Hans Z. di bawah ini - ini sekarang memang didefinisikan sebagai bagian dari RFC 7662 .

Jawaban Asli: Spesifikasi OAuth 2.0 ( RFC 6749 ) tidak secara jelas mendefinisikan interaksi antara Resource Server (RS) dan Server Otorisasi (AS) untuk validasi akses token (AT). Ini benar-benar tergantung pada format / strategi token AS - beberapa token bersifat mandiri (seperti JSON Web Token ) sementara yang lain mungkin mirip dengan cookie sesi karena mereka hanya mereferensikan informasi yang disimpan di sisi server di AS.

Ada beberapa diskusi dalam Kelompok Kerja OAuth tentang menciptakan cara standar bagi RS untuk berkomunikasi dengan AS untuk validasi AT. Perusahaan saya (Ping Identity) telah datang dengan salah satu pendekatan tersebut untuk komersial kami OAuth AS (PingFederate): https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001 . Ini menggunakan interaksi berbasis REST untuk ini yang sangat komplementer untuk OAuth 2.0.

Cara Google

Validasi Token Google Oauth2

Permintaan:

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

Menanggapi:

{
  "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
} 

Cara Microsoft

Microsoft - Oauth2 memeriksa otorisasi

Cara Github

Github - Oauth2 memeriksa otorisasi

Permintaan:

GET /applications/:client_id/tokens/:access_token

Menanggapi:

{
  "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"
  }
}

Cara Amazon

Login Dengan Amazon - Panduan Pengembang (Desember 2015, halaman 21)

Minta:

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

Tanggapan:

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
}

Pembaruan pada jawaban @Scott T.: antarmuka antara Server Sumber Daya dan Server Otorisasi untuk validasi token telah distandarisasi dalam IETF RFC 7662 pada Oktober 2015, lihat: https://tools.ietf.org/html/rfc7662 . Contoh panggilan validasi akan terlihat seperti:

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

dan contoh tanggapan:

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"
}

Tentu saja adopsi oleh vendor dan produk harus terjadi seiring waktu.

OAuth 2.0 spec tidak mendefinisikan bagian. Tetapi mungkin ada beberapa opsi:

1. Ketika server sumber daya mendapatkan token di Authz Header maka ia memanggil API validasi / introspeksi pada server Authz untuk memvalidasi token. Di sini Authz server dapat memvalidasinya baik dari menggunakan DB Store atau memverifikasi tanda tangan dan atribut tertentu. Sebagai bagian dari respons, ia memecahkan kode token dan mengirimkan data aktual token beserta sisa waktu kedaluwarsanya.

2. Authz Server dapat mengenkripsi / menandatangani token menggunakan kunci pribadi dan kemudian publickey / cert dapat diberikan ke Resource Server. Ketika server sumber daya mendapatkan token, itu baik mendekripsi / memverifikasi tanda tangan untuk memverifikasi token. Membawa konten keluar dan memproses token. Itu kemudian dapat memberikan akses atau menolak.

Spesifikasi OAuth v2 menunjukkan:

Atribut token akses dan metode yang digunakan untuk mengakses sumber daya yang dilindungi berada di luar cakupan spesifikasi ini dan ditentukan oleh spesifikasi pendamping.

Server Otorisasi Saya memiliki titik akhir layanan web (SOAP) yang memungkinkan Server Sumber Daya untuk mengetahui apakah access_token valid atau tidak.