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


147

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?


Server seharusnya dapat memvalidasi token yang sebelumnya telah dikeluarkan sendiri ... Biasanya ini akan menjadi pencarian basis data atau kripto (token yang ditandatangani sendiri).
Thilo

Saya melihat. Bagaimana dengan kasus ini, pemilik sumber daya WS dan klien WS keduanya pada perangkat yang berbeda?
Ack

5
Maksud Anda layanan otentikasi dan layanan sumber daya? (klien / konsumen akan selalu menggunakan perangkat yang berbeda, dan tidak dapat memvalidasi token sendiri). Jika demikian, Anda dapat menggunakan token penyegaran yang "mahal" untuk diperiksa (hanya server auth yang dapat melakukannya) tetapi berumur panjang dan mengakses token yang sering kedaluwarsa dan dapat diperiksa secara luring.
Thilo

Jawaban:


97

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.


Scott T, Apakah ada cara untuk melihat contoh kode tentang cara memanfaatkan fitur di Ping Federate?
JavaHead

2
@JavaHead ada beberapa detail protokol yang tercakup di situs web pengembang kami di sini: developer.pingidentity.com/en/resources/… , PingFederate OAuth Playground dikirimkan sebagai sekumpulan JSP yang dapat dirujuk sebagai kode sumber untuk memvalidasi token. Itu (dan pustaka serta sampel open source lainnya) dapat diunduh dari sini: developer.pingidentity.com/en/code.html
Scott T.

Scott, saya mencari sampel yang akan menunjukkan Hibah Kredensial Klien dengan API Istirahat yang dilindungi oleh Server Sumber Daya lokal dan PingFederate sebagai Server Auth. Server sumber daya lokal kemudian akan memanggil titik akhir validasi. Apakah Anda menemukan hal seperti itu?
JavaHead

@JavaHead lagi itu adalah sesuatu yang Anda harus bisa merujuk ke PingFederate OAuth Playground. Ini menunjukkan Jenis Hibah Kredensial Klien dan validasi Token Akses oleh Server Sumber Daya.
Scott T.

Dalam kasus token akses JWT, saya akan berasumsi bahwa Anda biasanya tidak ingin mencapai titik akhir introspeksi AS untuk setiap permintaan masuk ke RS. Dalam kasus apa, apakah pemeriksaan tanda tangan dan ruang lingkup token RS cukup? Atau, mungkin RS dapat menyimpan tanggapan introspeksi dari AS selama beberapa waktu?
Gary

119

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
}

2
@gustavodiazjaimes Tidak menjelaskan sama sekali bagaimana sisi server mengenali id ​​pengguna yang ditetapkan dari token.
user2284570

22
Saya tidak mengerti semua suara. Tampaknya ini tidak menjawab pertanyaan.
Duncan Jones

Adakah yang tahu apakah Azure Active Directory memiliki titik akhir yang serupa untuk memeriksa apakah token yang dikeluarkan valid?
user180940

2
Dengan kata lain, roll sendiri.
AndroidDev

51

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.


Jika menggunakan OoenId Connect tidak seharusnya kita lebih suka cara openid menggunakan token id untuk memvalidasi token akses: openid.net/specs/…
adnan kamili

1
@Renan: agar sejalan dengan cara lingkup diminta dalam permintaan otorisasi, yaitu dengan scopeparameter kueri yang nilainya berisi daftar ruang yang dipisahkan ruang
Hans Z.

4
Tolong jangan gunakan kata "standar" ketika sesuatu belum secara resmi diterima oleh badan pengelola. IETF RFC 7662 pada Februari 2018 dengan jelas menunjukkan bahwa itu adalah "proposal".
AndroidDev

1
@adnankamili Tidak ada yang namanya "proposal". Pada saat sebuah dokumen menjadi RFC, itu sudah menjadi "standar yang diusulkan" yang membawa bobot signifikan di baliknya. OAuth 2.0 sendiri masih merupakan "standar yang diusulkan" jadi saya tidak yakin poin apa yang ingin Anda sampaikan.
Pace

15

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.


8

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.