Mengautentikasi pengguna menggunakan Application Load Balancer - Elastic Load Balancing

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengautentikasi pengguna menggunakan Application Load Balancer

Anda dapat mengonfigurasi Application Load Balancer untuk mengautentikasi pengguna dengan aman saat mereka mengakses aplikasi Anda. Ini memungkinkan Anda untuk memindahkan pekerjaan mengautentikasi pengguna ke penyeimbang beban Anda sehingga aplikasi Anda dapat fokus pada logika bisnis mereka.

Contoh penggunaan berikut ini didukung:

  • Autentikasi pengguna melalui penyedia identitas (IdP) yang sesuai dengan OpenID Connect (OIDC).

  • Otentikasi pengguna melalui sosial IdPs, seperti Amazon, FaceBook, atau Google, melalui kumpulan pengguna yang didukung oleh Amazon Cognito.

  • Mengautentikasi pengguna melalui identitas perusahaan, menggunakan SAMP, OpenID Connect (OIDC), atau OAuth, melalui kumpulan pengguna yang didukung oleh Amazon Cognito.

Bersiap menggunakan IdP yang sesuai dengan OID

Lakukan hal berikut jika Anda menggunakan IdP yang sesuai dengan OIDC dengan Application Load Balancer Anda:

  • Buat aplikasi OIDC baru di IdP Anda. DNS iDP harus dapat diselesaikan secara publik.

  • Anda harus mengonfigurasi ID klien dan rahasia klien.

  • Dapatkan titik akhir berikut yang diterbitkan oleh IdP: otorisasi, token, dan info pengguna. Anda dapat menemukan informasi ini di konfigurasi.

  • Sertifikat endpoint IDP harus dikeluarkan oleh otoritas sertifikat publik tepercaya.

  • Entri DNS untuk titik akhir harus dapat diselesaikan secara publik, bahkan jika mereka memutuskan ke alamat IP pribadi.

  • Izinkan salah satu URL pengalihan berikut di aplikasi IdP Anda, mana pun yang akan digunakan pengguna Anda, dengan DNS adalah nama domain penyeimbang beban Anda dan CNAME adalah alias DNS untuk aplikasi Anda:

    • https://DNS/oauth2/idpresponse

    • https://CNAME/oauth2/idpresponse

Bersiap menggunakan Amazon Cognito

Integrasi Amazon Cognito untuk Application Load Balancers tersedia di wilayah berikut:

  • AS Timur (N. Virginia)

  • AS Timur (Ohio)

  • AS Barat (California Utara)

  • AS Barat (Oregon)

  • Kanada (Pusat)

  • Eropa (Stockholm)

  • Eropa (Milan)

  • Eropa (Frankfurt)

  • Eropa (Zürich)

  • Eropa (Irlandia)

  • Eropa (London)

  • Eropa (Paris)

  • Amerika Selatan (São Paulo)

  • Asia Pasifik (Tokyo)

  • Asia Pasifik (Seoul)

  • Asia Pasifik (Osaka)

  • Asia Pasifik (Mumbai)

  • Asia Pasifik (Singapura)

  • Asia Pasifik (Sydney)

  • Asia Pasifik (Jakarta)

  • Timur Tengah (UEA)

  • Timur Tengah (Bahrain)

  • Afrika (Cape Town)

  • Israel (Tel Aviv)

Lakukan hal berikut jika Anda menggunakan kolam pengguna Amazon Cognito dengan Application Load Balancer Anda:

  • Membuat pengguna. Untuk informasi lebih lanjut, lihat Kolam pengguna Amazon Cognito di Panduan Developer Amazon Cognito.

  • Membuat klien kolam pengguna. Anda harus mengonfigurasi klien untuk membuat rahasia klien, menggunakan alur pemberian kode, dan mendukung cakupan OAuth yang sama dengan yang digunakan penyeimbang beban. Untuk informasi lebih lanjut, lihat Mengonfigurasi klien aplikasi kolam pengguna di Panduan Developer Amazon Cognito.

  • Buat domain kolam pengguna. Untuk informasi lebih lanjut, lihat Menambahkan nama Domain untuk kolam pengguna di Panduan Developer Amazon Cognito.

  • Verifikasi bahwa cakupan yang diminta mengembalikan token ID. Misalnya, cakupan default, openid mengembalikan token ID tetapi cakupan aws.cognito.signin.user.admin tidak.

    Catatan: Application Load Balancer tidak mendukung token akses khusus yang dikeluarkan oleh Amazon Cognito. Untuk informasi selengkapnya, lihat Pra pembuatan token di Panduan Pengembang Amazon Cognito.

  • Untuk bergabung dengan IdP sosial atau perusahaan, aktifkan IdP di bagian federasi. Untuk informasi lebih lanjut, lihat Menambahkan sign-in sosial ke kolam pengguna atau Menambahkan sign-in dengan IdP SAML ke kolam pengguna di Panduan Developer Amazon Cognito.

  • Izinkan URL pengalihan berikut di bidang URL panggilan balik untuk Amazon Cognito, di mana DNS adalah nama domain penyeimbang beban Anda, dan CNAME adalah alias DNS untuk aplikasi Anda (jika Anda menggunakannya):

    • https://DNS/oauth2/idpresponse

    • https://CNAME/oauth2/idpresponse

  • Izinkan domain kolam pengguna Anda di URL panggilan balik aplikasi IdP Anda. Gunakan format untuk IdP Anda. Sebagai contoh:

    • https://domain-prefix.auth.region.amazoncognito.com/saml2/idpresponse

    • https://user-pool-domain/oauth2/idpresponse

URL callback di setelan klien aplikasi harus menggunakan semua huruf kecil.

Untuk memungkinkan pengguna mengonfigurasi penyeimbang beban agar menggunakan Amazon Cognito untuk mengautentikasi pengguna, Anda harus memberikan izin kepada pengguna untuk memanggil tindakan tersebut. cognito-idp:DescribeUserPoolClient

Bersiaplah untuk menggunakan Amazon CloudFront

Aktifkan pengaturan berikut jika Anda menggunakan CloudFront distribusi di depan Application Load Balancer Anda:

  • Header permintaan teruskan (semua) - Memastikan bahwa CloudFront tidak menyimpan respons cache untuk permintaan yang diautentikasi. Ini mencegah respons dilayani dari cache setelah sesi otentikasi berakhir. Atau, untuk mengurangi risiko ini saat caching diaktifkan, pemilik CloudFront distribusi dapat menetapkan nilai time-to-live (TTL) untuk kedaluwarsa sebelum cookie otentikasi berakhir.

  • Penerusan string kueri dan caching (semua) — Ensures that the load balancer has access to the query string parameters required to authenticate the user with the IdP.

  • Penerusan cookie (semua) — Memastikan bahwa CloudFront meneruskan semua cookie otentikasi ke penyeimbang beban.

Mengonfigurasi autentikasi pengguna

Anda mengonfigurasi autentikasi pengguna dengan membuat tindakan otentikasi untuk satu atau lebih aturan pendengar. Parameter authenticate-cognito dan authenticate-oidc jenis tindakan hanya didukung dengan listener HTTPS. Untuk deskripsi bidang terkait, lihat AuthenticateCognitoActionConfigdan AuthenticateOidcActionConfigdi Referensi API Elastic Load Balancing versi 2015-12-01.

Penyeimbang beban mengirimkan cookie sesi ke klien untuk mempertahankan status autentikasi. Cookie ini selalu berisi atribut secure, karena autentikasi pengguna memerlukan listener HTTPS. Cookie ini berisi atribut SameSite=None dengan permintaan CORS (berbagi sumber daya lintas-asal).

Untuk penyeimbang beban yang mendukung beberapa aplikasi yang memerlukan otentikasi klien independen, setiap aturan pendengar dengan tindakan otentikasi harus memiliki nama cookie yang unik. Ini memastikan bahwa klien selalu diautentikasi dengan IDP sebelum dirutekan ke grup target yang ditentukan dalam aturan.

Application Load Balancers tidak mendukung nilai-nilai cookie yang URL dikodekan.

Secara default, bidang SessionTimeout diatur ke 7 hari. Jika Anda ingin sesi yang lebih singkat, Anda dapat mengonfigurasi batas waktu sesi sesingkat 1 detik. Untuk informasi selengkapnya, lihat Batas waktu sesi habis.

Mengatur OnUnauthenticatedRequest bidang yang sesuai untuk aplikasi Anda. Sebagai contoh:

  • Aplikasi yang mengharuskan pengguna untuk log in menggunakan identitas sosial atau perusahaan—Ini didukung oleh opsi default, authenticate. Jika pengguna tidak log in, penyeimbang beban mengarahkan permintaan ke titik akhir otorisasi IdP dan IdP meminta pengguna untuk masuk menggunakan antarmuka pengguna.

  • Aplikasi yang menyediakan tampilan pribadi untuk pengguna yang masuk atau tampilan umum untuk pengguna yang tidak masuk—Untuk mendukung jenis aplikasi ini, gunakan pilihan allow. Jika pengguna masuk, penyeimbang beban memberikan klaim pengguna dan aplikasi dapat memberikan tampilan yang dipersonalisasi. Jika pengguna tidak masuk, penyeimbang beban meneruskan permintaan tanpa klaim pengguna dan aplikasi dapat memberikan tampilan umum.

  • Aplikasi satu halaman dengan JavaScript itu dimuat setiap beberapa detik —Jika Anda menggunakan deny opsi, penyeimbang beban mengembalikan kesalahan HTTP 401 Unauthorized ke panggilan AJAX yang tidak memiliki informasi otentikasi. Namun, jika pengguna memiliki informasi autentikasi yang kedaluwarsa, klien akan dialihkan ke titik akhir otorisasi IdP.

Penyeimbang beban harus dapat berkomunikasi dengan titik akhir token IdP (TokenEndpoint) dan titik akhir info pengguna IdP (UserInfoEndpoint). Application Load Balancers hanya mendukung IPv4 saat berkomunikasi dengan endpoint ini. Jika IDP Anda menggunakan alamat publik, pastikan grup keamanan untuk penyeimbang beban Anda dan ACL jaringan untuk VPC Anda mengizinkan akses ke titik akhir. Saat menggunakan penyeimbang beban internal atau jenis alamat IPdualstack-without-public-ipv4, gateway NAT dapat memungkinkan penyeimbang beban untuk berkomunikasi dengan titik akhir. Untuk informasi lebih lanjut, lihat dasar-dasar gateway NAT di Panduan Pengguna Amazon VPC.

Gunakan perintah buat-peraturan berikut untuk mengonfigurasi autentikasi pengguna.

aws elbv2 create-rule --listener-arn listener-arn --priority 10 \ --conditions Field=path-pattern,Values="/login" --actions file://actions.json

Berikut ini adalah contoh file actions.json yang menentukan tindakan authenticate-oidc dan tindakan forward. AuthenticationRequestExtraParams memungkinkan Anda meneruskan parameter tambahan ke IdP selama autentikasi. Harap ikuti dokumentasi yang disediakan oleh penyedia identitas Anda untuk menentukan bidang yang didukung

[{ "Type": "authenticate-oidc", "AuthenticateOidcConfig": { "Issuer": "https://idp-issuer.com", "AuthorizationEndpoint": "https://authorization-endpoint.com", "TokenEndpoint": "https://token-endpoint.com", "UserInfoEndpoint": "https://user-info-endpoint.com", "ClientId": "abcdefghijklmnopqrstuvwxyz123456789", "ClientSecret": "123456789012345678901234567890", "SessionCookieName": "my-cookie", "SessionTimeout": 3600, "Scope": "email", "AuthenticationRequestExtraParams": { "display": "page", "prompt": "login" }, "OnUnauthenticatedRequest": "deny" }, "Order": 1 }, { "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id", "Order": 2 }]

Berikut ini adalah contoh file actions.json yang menentukan tindakan authenticate-cognito dan tindakan forward.

[{ "Type": "authenticate-cognito", "AuthenticateCognitoConfig": { "UserPoolArn": "arn:aws:cognito-idp:region-code:account-id:userpool/user-pool-id", "UserPoolClientId": "abcdefghijklmnopqrstuvwxyz123456789", "UserPoolDomain": "userPoolDomain1", "SessionCookieName": "my-cookie", "SessionTimeout": 3600, "Scope": "email", "AuthenticationRequestExtraParams": { "display": "page", "prompt": "login" }, "OnUnauthenticatedRequest": "deny" }, "Order": 1 }, { "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id", "Order": 2 }]

Untuk informasi selengkapnya, lihat Peraturan listener.

Alur autentikasi

Diagram jaringan berikut adalah representasi visual tentang bagaimana Application Load Balancer menggunakan OIDC untuk mengautentikasi pengguna.

Cara Application Load Balancer mengautentikasi pengguna melalui OIDC

Item bernomor di bawah ini, menyorot dan menjelaskan elemen yang ditunjukkan dalam diagram jaringan sebelumnya.

  1. Pengguna mengirimkan permintaan HTTPS ke situs web yang dihosting di belakang Application Load Balancer. Saat syarat peraturan dengan tindakan autentikasi terpenuhi, penyeimbang beban memeriksa cookie sesi autentikasi di header permintaan.

  2. Jika cookie tidak ada, penyeimbang beban mengalihkan pengguna ke titik akhir otorisasi IdP sehingga IdP dapat mengautentikasi pengguna.

  3. Setelah pengguna diautentikasi, IdP mengirim pengguna kembali ke penyeimbang beban dengan kode pemberian otorisasi.

  4. Penyeimbang beban menyajikan kode pemberian otorisasi ke titik akhir token IdP.

  5. Setelah menerima kode pemberian otorisasi yang valid, IdP memberikan token ID dan token akses ke Application Load Balancer.

  6. Application Load Balancer kemudian mengirimkan token akses ke titik akhir info pengguna.

  7. Titik akhir info pengguna menukar token akses dengan klaim pengguna.

  8. Application Load Balancer mengalihkan pengguna dengan cookie sesi AWSELB otentikasi ke URI asli. Karena sebagian besar browser membatasi ukuran cookie hingga 4K, penyeimbang beban membagi cookie yang berukuran lebih besar dari 4K menjadi beberapa cookie. Jika ukuran total klaim pengguna dan token akses yang diterima dari IdP lebih besar dari 11K byte, penyeimbang beban mengembalikan kesalahan HTTP 500 ke klien dan menambah metrik ELBAuthUserClaimsSizeExceeded.

  9. Application Load Balancer memvalidasi cookie dan meneruskan info pengguna ke target di X-AMZN-OIDC-* set header HTTP. Untuk informasi selengkapnya, lihat Pengkodean klaim pengguna dan verifikasi tanda tangan.

  10. Target mengirimkan respons kembali ke Application Load Balancer.

  11. Application Load Balancer mengirimkan respons akhir kepada pengguna.

Setiap permintaan baru berjalan melalui langkah 1 sampai 11, sementara permintaan berikutnya melalui langkah 9 sampai 11. Artinya, setiap permintaan berikutnya dimulai pada langkah 9 selama cookie belum kedaluwarsa.

AWSALBAuthNonceCookie ditambahkan ke header permintaan setelah pengguna mengautentikasi di IDP. Ini tidak mengubah cara Application Load Balancer memproses permintaan pengalihan dari IDP.

Jika IdP menyediakan token penyegaran yang valid dalam token ID, penyeimbang beban akan menyimpan token penyegaran dan menggunakannya untuk menyegarkan klaim pengguna setiap kali token akses kedaluwarsa, hingga waktu sesi habis atau penyegaran IdP gagal. Jika pengguna log out, penyegaran gagal dan penyeimbang beban mengalihkan pengguna ke titik akhir otorisasi IdP. Hal ini memungkinkan penyeimbang beban untuk mengakhiri sesi setelah pengguna log out. Untuk informasi selengkapnya, lihat Batas waktu sesi habis.

catatan

Kedaluwarsa cookie berbeda dari kedaluwarsa sesi autentikasi. Kedaluwarsa cookie adalah atribut cookie, yang diatur ke 7 hari. Panjang sebenarnya dari sesi autentikasi ditentukan oleh batas waktu sesi yang dikonfigurasi pada Application Load Balancer untuk fitur autentikasi. Waktu habis sesi ini termasuk dalam nilai cookie Auth, yang juga dienkripsi.

Pengkodean klaim pengguna dan verifikasi tanda tangan

Setelah penyeimbang beban Anda berhasil mengautentikasi pengguna, ia akan mengirimkan klaim pengguna yang diterima dari IdP ke target. Penyeimbang beban menandatangani klaim pengguna sehingga aplikasi dapat memverifikasi tanda tangan dan memverifikasi bahwa klaim dikirim oleh penyeimbang beban.

Penyeimbang beban menambahkan header HTTP berikut:

x-amzn-oidc-accesstoken

Token akses dari titik akhir token, dalam teks biasa.

x-amzn-oidc-identity

Bidang subjek (sub) dari titik akhir info pengguna, dalam teks biasa.

Catatan: Sub klaim adalah cara terbaik untuk mengidentifikasi pengguna tertentu.

x-amzn-oidc-data

Klaim pengguna, dalam format token web JSON (JWT).

Token akses dan klaim pengguna berbeda dari token ID. Token akses dan klaim pengguna hanya mengizinkan akses ke sumber daya server, sementara token ID membawa informasi tambahan untuk mengautentikasi pengguna. Application Load Balancer membuat token akses baru saat mengautentikasi pengguna dan hanya meneruskan token akses dan klaim ke backend, namun tidak meneruskan informasi token ID.

Token ini mengikuti format JWT tetapi bukan ID token. Format JWT mencakup header, payload, dan tanda tangan yang dikodekan URL base64, dan menyertakan karakter padding di bagian akhir. Application Load Balancer menggunakan ES256 (ECDSA menggunakan P-256 dan SHA256) untuk menghasilkan tanda tangan JWT.

Header JWT adalah objek JSON dengan bidang-bidang berikut:

{ "alg": "algorithm", "kid": "12345678-1234-1234-1234-123456789012", "signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id", "iss": "url", "client": "client-id", "exp": "expiration" }

Muatan JWT adalah objek JSON yang berisi klaim pengguna yang diterima dari endpoint info pengguna IdP.

{ "sub": "1234567890", "name": "name", "email": "alias@example.com", ... }

Karena penyeimbang beban tidak mengenkripsi klaim pengguna, kami menyarankan Anda mengonfigurasi grup target untuk menggunakan HTTPS. Jika Anda mengonfigurasi grup target untuk menggunakan HTTP, pastikan untuk membatasi lalu lintas ke penyeimbang beban Anda menggunakan grup keamanan.

Untuk memastikan keamanan, Anda harus memverifikasi tanda tangan sebelum melakukan otorisasi berdasarkan klaim dan memvalidasi bahwa signer bidang di header JWT berisi ARN Application Load Balancer yang diharapkan.

Untuk mendapatkan kunci publik, dapatkan ID kunci dari header JWT dan gunakan untuk mencari kunci publik dari titik akhir. Titik akhir untuk setiap AWS Wilayah adalah sebagai berikut:

https://public-keys.auth.elb.region.amazonaws.com/key-id

Untuk AWS GovCloud (US), titik akhir adalah sebagai berikut:

https://s3-us-gov-west-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-west-1/key-id https://s3-us-gov-east-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-east-1/key-id

Contoh berikut menunjukkan cara mendapatkan ID kunci, kunci publik, dan payload di Python 3.x:

import jwt import requests import base64 import json # Step 1: Validate the signer expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id' encoded_jwt = headers.dict['x-amzn-oidc-data'] jwt_headers = encoded_jwt.split('.')[0] decoded_jwt_headers = base64.b64decode(jwt_headers) decoded_jwt_headers = decoded_jwt_headers.decode("utf-8") decoded_json = json.loads(decoded_jwt_headers) received_alb_arn = decoded_json['signer'] assert expected_alb_arn == received_alb_arn, "Invalid Signer" # Step 2: Get the key id from JWT headers (the kid field) kid = decoded_json['kid'] # Step 3: Get the public key from regional endpoint url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid req = requests.get(url) pub_key = req.text # Step 4: Get the payload payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

Contoh berikut menunjukkan cara mendapatkan ID kunci, kunci publik, dan payload di Python 2.7:

import jwt import requests import base64 import json # Step 1: Validate the signer expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id' encoded_jwt = headers.dict['x-amzn-oidc-data'] jwt_headers = encoded_jwt.split('.')[0] decoded_jwt_headers = base64.b64decode(jwt_headers) decoded_json = json.loads(decoded_jwt_headers) received_alb_arn = decoded_json['signer'] assert expected_alb_arn == received_alb_arn, "Invalid Signer" # Step 2: Get the key id from JWT headers (the kid field) kid = decoded_json['kid'] # Step 3: Get the public key from regional endpoint url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid req = requests.get(url) pub_key = req.text # Step 4: Get the payload payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])
Pertimbangan
  • Contoh-contoh ini tidak mencakup cara memvalidasi tanda tangan penerbit dengan tanda tangan di token.

  • Pustaka standar tidak kompatibel dengan padding yang disertakan dalam token otentikasi Application Load Balancer dalam format JWT.

Waktu habis

Batas waktu sesi habis

Token penyegaran dan batas waktu sesi bekerja bersama sebagai berikut:

  • Jika batas waktu sesi lebih pendek dari masa kedaluwarsa token akses, penyeimbang beban menghormati batas waktu sesi. Jika pengguna memiliki sesi aktif dengan IdP, pengguna mungkin tidak diminta untuk log in lagi. Jika tidak, pengguna diarahkan untuk log in.

    • Jika batas waktu sesi IdP lebih lama dari batas waktu sesi Application Load Balancer, pengguna tidak perlu memberikan kredensial untuk log in lagi. Sebagai gantinya, IdP mengalihkan kembali ke Application Load Balancer dengan kode pemberian otorisasi baru. Kode otorisasi adalah penggunaan tunggal, bahkan jika tidak ada login ulang.

    • Jika batas waktu sesi IdP sama dengan atau lebih pendek dari batas waktu sesi Application Load Balancer, pengguna akan diminta untuk memberikan kredensial untuk log in lagi. Setelah pengguna masuk, IdP mengalihkan kembali ke Application Load Balancer dengan kode pemberian otorisasi baru, dan alur autentikasi lainnya berlanjut hingga permintaan mencapai backend.

  • Jika batas waktu sesi lebih lama dari masa berlaku token akses dan IdP tidak mendukung token penyegaran, penyeimbang beban akan mempertahankan sesi autentikasi hingga waktu habis. Kemudian, sesi akan meminta pengguna log in lagi.

  • Jika batas waktu sesi lebih lama dari masa berlaku token akses dan IdP mendukung token penyegaran, penyeimbang beban akan menyegarkan sesi pengguna setiap kali token akses kedaluwarsa. Penyeimbang beban meminta pengguna log in lagi hanya setelah sesi autentikasi habis atau aliran penyegaran gagal.

Batas waktu login klien

Klien harus memulai dan menyelesaikan proses otentikasi dalam waktu 15 menit. Jika klien gagal menyelesaikan otentikasi dalam batas 15 menit, ia menerima kesalahan HTTP 401 dari penyeimbang beban. Batas waktu ini tidak dapat diubah atau dihapus.

Misalnya, jika pengguna memuat halaman login melalui Application Load Balancer, mereka harus menyelesaikan proses login dalam waktu 15 menit. Jika pengguna menunggu dan kemudian mencoba masuk setelah batas waktu 15 menit berakhir, penyeimbang beban mengembalikan kesalahan HTTP 401. Pengguna harus me-refresh halaman dan mencoba masuk lagi.

Logout autentikasi

Saat aplikasi perlu me-logout pengguna yang diautentikasi, aplikasi harus menyetel waktu kedaluwarsa cookie sesi autentikasi ke -1 dan mengarahkan klien ke titik akhir logout IdP (jika IdP mendukungnya). Untuk mencegah pengguna menggunakan kembali cookie yang dihapus, kami menyarankan Anda untuk mengonfigurasi sesingkat waktu kedaluwarsa untuk token akses yang wajar. Jika klien menyediakan penyeimbang beban dengan cookie sesi yang memiliki token akses kedaluwarsa dengan token penyegaran non-NULL, penyeimbang beban menghubungi IdP untuk menentukan apakah pengguna masih masuk.

Halaman arahan logout klien adalah halaman yang tidak diautentikasi. Ini berarti bahwa itu tidak boleh berada di belakang aturan Application Load Balancer yang memerlukan autentikasi.

  • Ketika permintaan dikirim ke target, aplikasi harus mengatur kedaluwarsa ke -1 untuk semua cookie autentikasi. Application Load Balancer mendukung cookie hingga ukuran 16K dan karenanya dapat membuat hingga 4 pecahan untuk dikirim ke klien.

    • Jika IdP memiliki titik akhir logout, IdP harus mengeluarkan pengalihan ke titik akhir logout IdP, misalnya, Titik Akhir LOGOUT yang terdokumentasi di Panduan Developer Amazon Cognito.

    • Jika IdP tidak memiliki titik akhir logout, permintaan akan kembali ke halaman arahan logout klien, dan proses login dimulai ulang.

  • Dengan asumsi bahwa IdP memiliki titik akhir logout, IdP harus kedaluwarsa token akses dan token penyegaran, dan mengarahkan pengguna kembali ke halaman arahan logout klien.

  • Permintaan berikutnya mengikuti alur autentikasi asli.