RESTful API'sında jeton yenileme / oturum sona erme durumunu işleme

Kullanıcı kimlik doğrulaması için JWT belirteçleri (bir loginbitiş noktası tarafından yayınlanan ve daha sonra tüm üstbilgilere gönderilen) kullanan RESTful API oluşturuyorum ve belirteçler, sabit bir süre sonra yenilenmesi gerekiyor ( renewyenilenen bir belirteç döndüren bir bitiş noktası çağrılıyor) ).

Bir kullanıcının API oturumunun jetonun süresi dolmadan geçersiz hale gelmesi olasıdır, bu nedenle tüm uç noktalarım aşağıdakileri kontrol ederek başlar: 1) jeton hala geçerli ve 2) kullanıcının oturumu hala geçerli. Jetonu doğrudan geçersiz kılmanın bir yolu yoktur, çünkü istemciler yerel olarak saklar.

Bu nedenle, tüm uç noktalarımın müşterilerime iki olası koşuldan bahsetmesi gerekir: 1) jetonu yenileme zamanı veya 2) oturumun geçersiz hale gelmesi ve artık sisteme erişmesine izin verilmiyor. İki koşuldan biri ortaya çıktığında uç noktalarımın müşterilerine sinyal vermesi için iki alternatif düşünebilirim (müşterilerin her iki seçeneğe de uyarlanabileceğini varsayın):

1. Oturum geçersiz hale geldiyse bir http 401 kodu (yetkisiz) döndürün veya belirtecin süresi dolduğunda 412 kodu (önkoşul başarısız oldu) döndürün ve renew200 (ok) kod döndürecek bitiş noktasını çağırmanın zamanı geldi .
2. Oturumun geçersiz olduğunu veya belirtecin süresinin dolduğunu bildirmek için 401 değerini döndürün. Bu durumda, istemci hemen renewbitiş noktasını çağırır , eğer 200 döndürürse jeton yenilenir, ancak renew401 döndürürse, istemci sistemin dışında kaldığı anlamına gelir.

Yukarıdaki iki seçenekten hangisini önerirsiniz? Hangisi daha standart, anlaşılması daha basit ve / veya daha RESTful olur? Yoksa tamamen farklı bir yaklaşım önerir misiniz? Her iki seçenekte de belirgin sorunlar veya güvenlik riskleri görüyor musunuz? Cevabınız görüşünüzü destekleyen harici referanslar içeriyorsa ekstra puanlar.

GÜNCELLEME

Çocuklar, lütfen asıl soruya odaklanın - bir yenileme / oturum geçersiz kılma sinyalini vermek için iki http kodu alternatifinden hangisi en iyisidir? Sistemimin JWT ve sunucu tarafı oturumlarını kullandığı gerçeğine aldırmayın, bu benim çok özel iş kuralları için API'mın bir özelliği ve yardım aradığım kısım değil;)

Bu bir durumda gibi geliyor kimlik doğrulama karşı yetkilendirme .

JWT'ler, bir talebin kaynağı hakkında kriptografik olarak imzalanmış iddialardır. Bir JWT, "Bu istek X kullanıcısı içindir" ve "X Kullanıcısının yönetici rolleri vardır" gibi talepler içerebilir. Parolalar, imzalar ve TLS aracılığıyla bu kanıtı elde etmek ve sağlamak, kimlik doğrulaması alanıdır - söylediğiniz kişi olduğunuzu kanıtlar.

Bu hak taleplerinin sunucunuz için ne anlama geldiği - belirli kullanıcıların ve rollerin yapmasına izin verilen - yetkilendirme sorunudur . İkisi arasındaki fark iki senaryo ile açıklanabilir. Bob'un şirketinin deposunun kısıtlı depolama bölümüne girmek istediğini, ancak önce Jim adlı bir gardiyanla uğraşması gerektiğini varsayalım.

Senaryo A - Kimlik Doğrulama

• Bob: "Merhaba Jim, kısıtlı depolama alanına girmek istiyorum."
• Jim: "Rozetini aldın mı?"
• Bob: "Hayır, unuttun."
• Jim: "Üzgünüm dostum, rozetsiz giriş yok."

Senaryo B - Yetkilendirme

• Bob: "Merhaba Jim, kısıtlı depolama alanına girmek istiyorum. İşte rozetim."
• Jim: "Hey Bob, buraya girmek için seviye 2 açıklığına ihtiyacın var. Üzgünüm."

JWT sona erme süreleri, başkalarının bunları çalmasını önlemek için kullanılan bir kimlik doğrulama cihazıdır. Tüm JWT'lerinizin beş dakikalık sona erme süreleri varsa, çalınmaları neredeyse büyük bir anlaşma değildir, çünkü hızla işe yaramaz hale gelirler. Ancak, tartıştığınız "oturumun sona ermesi" kuralı, bir yetkilendirme sorunu gibi geliyor. Durumdaki bazı değişiklikler, X kullanıcısının artık eskiden yapabileceği bir şeyi yapmasına izin verilmediği anlamına gelir. Örneğin, Bob kullanıcısı işten çıkarılmış olabilir - rozetinin artık Bob olduğunu söylemesinin bir önemi yok, çünkü Bob olmak artık ona şirketle yetki vermiyor.

Bu iki durumda ayrı HTTP yanıt kodları vardır: 401 Unauthorizedve 403 Forbidden. Maalesef adlandırılmış 401 kodu, eksik, süresi dolmuş veya iptal edilmiş kimlik bilgileri gibi kimlik doğrulama sorunları içindir. 403, sunucunun kim olduğunuzu tam olarak bildiği yetkilendirme içindir, ancak yapmaya çalıştığınız şeyi yapmanıza izin verilmez. Bir kullanıcının hesabının silinmesi durumunda, bitiş noktasında bir JWT ile bir şeyler yapmaya çalışmak 403 Yasak yanıtla sonuçlanır. Ancak, JWT'nin süresi dolmuşsa, doğru sonuç 401 Yetkisiz olur.

Ortak bir JWT paterni "uzun ömürlü" ve "kısa ömürlü" jetonlara sahip olmaktır. Uzun ömürlü jetonlar, kısa ömürlü jetonlar gibi istemcide depolanır, ancak kapsamı sınırlıdır ve yalnızca kısa ömürlü jetonlar almak için yetkilendirme sisteminizle birlikte kullanılır. Uzun ömürlü jetonlar, adından da anlaşılacağı gibi, çok uzun sona erme sürelerine sahiptir - bunları günlerce veya haftalarca yeni jetonlar istemek için kullanabilirsiniz. Kısa ömürlü jetonlar, tanımladığınız jetonlardır ve sisteminizle etkileşim kurmak için çok kısa süre sonu süreleriyle kullanılır. Uzun ömürlü jetonlar Beni Hatırla işlevini uygulamak için kullanışlıdır, bu nedenle yeni bir kısa ömürlü jeton almak için her beş dakikada bir şifrenizi girmeniz gerekmez.

Açıkladığınız "oturum geçersiz kılma" sorunu, kısa ömürlü olanları nadiren sunucu tarafında, uzun ömürlü olanların ise iptal edilmesi gerektiğinde izlendiğinden, uzun ömürlü bir JWT'yi geçersiz kılmaya çalıştığınız sesleri benzer. Böyle bir sistemde, uzun ömürlü bir jetonla kimlik bilgileri edinmeye çalışmak 401 Yetkisiz ile sonuçlanır, çünkü kullanıcı teknik olarak kimlik bilgilerini alabilir, ancak kullandıkları jeton görev için uygun değildir. Daha sonra kullanıcı, kullanıcı adını ve şifresini kullanarak yeni bir uzun ömürlü jeton almaya çalıştığında, sistem dışarı atılırsa 403 Yasak ile yanıt verebilir.

API oturumunuz RESTful dünyasında hiç olmaması gereken bir şeydir. RESTful operasyonlarının vatansız olması gerekiyor, oturum devlet içeriyor ve RESTful dünyasında yeri yok.

JWT, bir kullanıcının hala bir uç noktaya erişmeye uygun olup olmadığını belirlemenin tek yolu olmalıdır. Bir oturumda kesinlikle hiçbir rol oynamamalıdır. Varsa, RESTful API'niz yoktur.

Oturumu tamamen ortadan kaldırdığınızda, bir RESTful API'yi hedefliyorsanız ve JWT'yi yalnızca bir kimlik doğrulama faktörü olarak kullanmanız durumunda, bir kullanıcı uç noktanızı kullanmaya yetkilidir ya da kullanmaz - bu durumda 401 Unauthorizedyanıt kodu uygundur - ve çağırmalıdır renewile bitiş noktası grant_type=refresh_tokenyenilenmesi ya da her türlü kimlik kullandığınız.

Güncelleme:

Yorumdan şu anda kullandığınız JWT'nin doğrulama akışı doğru değil gibi görünüyor. Doğrulamanın şöyle görünmesi gerekiyor:

  Client        RESTful API      JWT Issuer
     |              |                |
     |----- 1. ---->|                | 
     |              |------ 2. ----->|-----
     |              |                | 3. |
     |              |<----- 4. ------|<----
-----|<---- 5. -----|                |
| 6. |              |                |
---->|----- 7. ---->|                |
     |              |------ 8. ----->|-----
     |              |                | 9. |
     |              |<----- 10. -----|<----
     |              |                |
     |              |------          |
     |              | 11. |          |
     |<---- 12. ----|<-----          |
     |              |                |
     .              .                .

1. Ask RESTful API for a JWT using login endpoint.
2. Ask Issuer to create a new JWT.
3. Create JWT.
4. Return JWT to the RESTful API.
5. Return JWT to Client.
6. Store JWT to append it to all future API requests.
7. Ask for data from API providing JWT as authorization.
8. Send JWT to Issuer for verification.
9. Issuer verifies JWT.
10. Issuer returns 200 OK, verification successful.
11. Retrieve and format data for Client.
12. Return data to Client.

Sunucunun, RESTful APIYetkilendirme olarak gönderilen belirtecin geçerliliğini denetlemesi gerekir. Bu onun sorumluluğu değil Client. Şu anda bunu yapmıyorsunuz gibi görünüyor. JWT'nin doğrulamasını bu şekilde uygulayın ve oturumlara hiç ihtiyacınız yoktur.

Bu yüzden, oturumla REST sözleşmelerini zaten kırdığınızda hangi yaklaşımın en RESTful olduğu konusunda endişelenmemin pek mantıklı olmadığını itiraf edeceğim, ancak iş gereksinimlerinizi karşıladığınızı anlıyorum.

Bir REST açısından, istemcinin kimliği doğrulanır veya doğrulanmaz. Mimari neden (umursamaz durum enjekte ediyor) çok fazla umursamıyor, bu yüzden ana sorunuza cevap vermek için, hiçbir şekilde yenilenen bir son noktaya sahip olmazdım. Oturum açmış bir istemci her zaman JWT'lerini gönderir ve sunucu her zaman doğrular ve eylem 200, 201, vb. Temel alınarak uygun Başarı kodunu göndererek kabul eder) veya uygun şekilde 401 veya 403 ile reddeder.

Şimdi, JWT bir tür hesapla ilişkilendirilecek. Bu hesap kilitlenebilir veya daraltılabilir ya da her neyse, bu nedenle jetonun kendisi geçerli olabilir, ancak eylem yine de başka yerlerde reddedilebilir. Durum, kullanıcı hesabının iş kuralları nedeniyle kilitli olması durumunda, müşteriye ne kadar bilgi vermek istediğinize bağlı olarak hala 401 veya 403'tür (farklı işletmeler bu konuda farklı görüşlere sahiptir).

Son olarak, hesabın kilidinin açılmış ve geçerli olabileceğini iddia ediyorsanız, ancak JWT'nin iptal edilmesi gerekiyorsa, o zaman 401 veya 403 ile devam edeceğim ve bir tane koyabileceğiniz geçersiz JWT'lerin Sertifika İptal Listesi gibi bir şeyi koruyacağım , JWT'nin süresi dolduğunda kendini temizlediği sürece (çoğu veritabanının bunu yapmanın bir yolu vardır veya uygulama kodunda etkinlikler olabilir).