Taslak OAuth 2.0 protokolünün Bölüm 4.2'si, bir yetkilendirme sunucusunun hem access_tokenyalnızca (bir kaynakla kendini doğrulamak için kullanılır) hem de refresh_tokenyalnızca yeni bir oluşturmak için kullanılan a'yı döndürebileceğini gösterir access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Neden ikisi de var? Neden sadece access_tokensonuncusu refresh_tokenyapmıyorsunuz ve bir refresh_token?
Yanıtlar:
Yenileme belirteçleri fikri, bir erişim belirtecinin ele geçirilmesi durumunda, kısa ömürlü olduğu için, saldırganın onu kötüye kullanacağı sınırlı bir pencereye sahip olmasıdır.
Yenileme simgeleri, ele geçirildiyse işe yaramaz çünkü saldırgan bir erişim belirteci kazanmak için yenileme belirtecine ek olarak istemci kimliği ve sır ister.
Bununla birlikte , hem yetkilendirme sunucusuna hem de kaynak sunucusuna yapılan her çağrı SSL üzerinden yapıldığından - erişim / yenileme belirteçlerini istediklerinde orijinal istemci kimliği ve sırrı dahil - Erişim belirtecinin artık nasıl olduğundan emin değilim " uzun ömürlü yenileme jetonu ve müşteri kimliği / gizli kombinasyonundan daha uzlaşabilir.
Bu, elbette, hem yetkilendirmeyi hem de kaynak sunucularını denetlemediğiniz uygulamalardan farklıdır.
İşte yenileme jetonlarının kullanımı hakkında iyi bir iş parçacığı: OAuth Archives .
Yenileme belirtecinin güvenlik amaçlarından bahseden yukarıdan bir alıntı:
Belirteçleri yenile ... uzun ömürlü bir erişim_dönmesi sızıntısı riskini azaltır (güvenli olmayan bir kaynak sunucudaki bir günlük dosyasındaki sorgu parametresi, beta veya kötü kodlanmış bir kaynak sunucu uygulaması, https olmayan bir sitedeki JS SDK istemcisi, çerez vb.)
Catchdave tarafından sağlanan tartışma bağlantısının , Dick Hardt tarafından yapılan, yukarıda yazılanlara ek olarak burada belirtilmeye değer olduğuna inandığım başka bir geçerli nokta (orijinal, ölü bağlantı) var:
Yenileme jetonlarını hatırlamam güvenlik ve iptali içindi. <...>
iptal: erişim belirteci kendi kendine yetiyorsa, yetkilendirme yeni erişim belirteçleri verilmezse iptal edilebilir. Bir kaynağın, erişim belirtecinin geçerli olup olmadığını görmek için yetkilendirme sunucusunu sorgulaması gerekmez. Bu, erişim belirteci doğrulamasını basitleştirir ve birden çok yetkilendirme sunucusunu ölçeklendirmeyi ve desteklemeyi kolaylaştırır. Bir erişim belirtecinin geçerli olduğu, ancak yetkilendirmenin iptal edildiği bir zaman penceresi vardır.
Gerçekten de, Kaynak Sunucu ile Yetkilendirme Sunucusunun aynı varlık olduğu ve kullanıcı ile bunlardan biri arasındaki bağlantının (genellikle) eşit derecede güvenli olduğu durumlarda, yenileme belirtecini erişim belirtecinden ayrı tutmanın pek bir anlamı yoktur.
Alıntıda belirtildiği gibi, yenileme belirteçlerinin başka bir rolü, erişim belirtecinin, sistemi aynı anda ölçeklenebilir tutarken Kullanıcı tarafından herhangi bir zamanda (örneğin profillerindeki web arabirimi aracılığıyla) iptal edilmesini sağlamaktır. .
Genellikle, jetonlar ya Sunucu'nun veritabanındaki belirli bir kaydı işaret eden rastgele tanımlayıcılar olabilir ya da kendi içindeki tüm bilgileri içerebilirler (kesinlikle bu bilgilerin örneğin MAC ile imzalanması gerekir ).
Uzun ömürlü erişim belirteçlerine sahip sistem nasıl çalışmalıdır?
Sunucu, Müşterinin bir belirteç vererek önceden tanımlanmış bir kapsam kümesi içinde Kullanıcı verilerine erişmesine izin verir. Simgeyi iptal edilebilir tutmak istediğimizden, "iptal edilmiş" bayrağı ayarlanmış veya ayarlanmamış olarak belirteci veritabanında depolamalıyız (aksi halde, bunu kendi içinde bulunan jetonla nasıl yaparsınız?) Veritabanı, len(users) x len(registered clients) x len(scopes combination)kayıt kadar içerebilir . Her API isteğinin veritabanına ulaşması gerekir. Her ne kadar O (1) performans gösteren bu tür veritabanında sorgu yapmak oldukça önemsiz olsa da, tek hata noktasının kendisi sistemin ölçeklenebilirliği ve performansı üzerinde olumsuz etkiye sahip olabilir.
Uzun ömürlü yenileme belirteci ve kısa ömürlü erişim belirtecine sahip sistem nasıl çalışmalıdır?
Burada iki anahtar veriyoruz: veritabanındaki ilgili kayıtla rastgele yenileme belirteci ve diğerlerinin yanı sıra son kullanma süresi damgası alanını içeren imzalı bağımsız erişim belirteci.
Erişim jetonu kendi içinde olduğundan, geçerliliğini kontrol etmek için veritabanına hiç çarpmak zorunda değiliz. Tek yapmamız gereken belirteci çözmek ve imzayı ve zaman damgasını doğrulamak.
Bununla birlikte, yenileme jetonlarının veritabanını hala tutmalıyız, ancak bu veritabanına yapılan isteklerin sayısı genellikle erişim belirtecinin ömrü ile tanımlanır (kullanım süresi uzadıkça, erişim oranı düşer).
İstemcinin belirli bir Kullanıcıdan erişimini iptal etmek için, ilgili yenileme jetonunu "iptal edildi" olarak işaretlemeli (veya tamamen kaldırmalıyız) ve yeni erişim belirteçleri vermeyi durdurmalıyız. Yenileme belirtecinin iptal edildiği bir pencere olduğu açıktır, ancak erişim belirteci hala geçerli olabilir.
tradeoffs
Yenileme belirteçleri, Access Token veritabanının SPoF'sini (Tek Hata Noktası) kısmen ortadan kaldırır, ancak bazı belirgin dezavantajları vardır.
Pencere". "Kullanıcı erişimi iptal eder" ve "erişimin iptal edileceğini garanti eder" olayları arasındaki bir zaman aralığı.
İstemci mantığının karmaşıklığı.
yenileme jetonu olmadan
ile yenileme jetonu
Umarım bu cevap mantıklıdır ve birisinin daha düşünceli bir karar vermesine yardımcı olur. Ayrıca github ve oturaklı da dahil olmak üzere bazı tanınmış OAuth2 sağlayıcılarının yenileme jetonları olmadan protokolü benimsediğini ve bundan memnun olduğunu belirtmek isterim.
Yukarıdaki tüm harika cevaplara rağmen, daha önce eBay'de alıcı koruması ve sahtekarlığına baktığımda çalışan bir güvenlik ustası öğrencisi ve programcısı olarak, ayrı erişim belirteci ve yenileme belirtecinin sık kullanılan kullanıcı adını rahatsız eden kullanıcı arasında en iyi dengeye sahip olduğunu söyleyebilirim / şifre girişi ve hizmetinizin potansiyel kötüye kullanımına erişimi iptal etme yetkisini el altında tutmak .
Böyle bir senaryo düşünün. Kullanıcıya 3600 saniyelik erişim jetonu veriyorsunuz ve jetonu bir günden daha uzun süre yeniliyorsunuz.
Kullanıcı iyi bir kullanıcıdır, evde ve iPhone'unda alışveriş ve arama yaparak web sitenizi açar / kapatır. IP adresi değişmez ve sunucunuzda çok düşük bir yüke sahiptir. Her dakikada 3-5 sayfa isteği gibi. Erişim belirtecindeki 3600 saniyesi sona erdiğinde, yenileme belirteciyle yeni bir tane gerektiriyor. Sunucu tarafında, etkinlik geçmişini ve IP adresini kontrol ediyoruz, onun bir insan olduğunu ve kendisinin davrandığını düşünüyoruz. Hizmetimizi kullanmaya devam etmesi için ona yeni bir erişim jetonu veriyoruz. Kullanıcının bir gün yenileme belirtecinin kendisine ulaşana kadar kullanıcı adını / şifreyi tekrar girmesi gerekmez.
Kullanıcı dikkatsiz bir kullanıcıdır. ABD , New York'ta yaşıyor ve virüs programını kapattı ve Polonya'daki bir hacker tarafından hacklendi . Bilgisayar korsanı erişim belirteci ve yenileme belirtecini aldığında kullanıcıyı taklit etmeye ve hizmetimizi kullanmaya çalışır. Ancak kısa süreli erişim belirtecinin süresi dolduktan sonra, bilgisayar korsanı erişim belirtecini yenilemeye çalıştığında, sunucuda kullanıcı davranış geçmişinde önemli bir IP değişikliği fark ettik (hey, bu adam ABD'de oturum açıyor ve şimdi Polonya'da erişimi yeniliyor sadece 3600'lerden sonra ???). Yenileme işlemini sonlandırır, yenileme jetonunun kendisini geçersiz kılar ve kullanıcı adını / şifreyi tekrar girmenizi isteriz.
Kullanıcı kötü niyetli bir kullanıcıdır. Bir robot kullanarak her dakika 1000 defa API'mızı arayarak hizmetimizi kötüye kullanmayı amaçlıyor. Bunu 3600 saniye sonra yapabilir, erişim belirtecini yenilemeye çalıştığında, davranışını fark ettik ve onun insan olmadığını düşünüyoruz. Yenileme işlemini reddeder ve sonlandırırız ve ondan tekrar kullanıcı adı / şifre girmesini isteriz. Bu, potansiyel olarak robotunun otomatik akışını kırabilir. En azından onu rahatsız ediyor.
İşimizi, kullanıcı deneyimimizi ve çalıntı jetonun potansiyel riskini dengelemeye çalıştığımızda yenileme jetonunun mükemmel bir şekilde hareket ettiğini görebilirsiniz. Sunucu tarafındaki saat köpeğiniz, kullanıcının iyi bir kullanıcı olup olmadığını belirlemek için IP değişikliğinden, api çağrılarının sıklığından daha fazlasını kontrol edebilir.
Başka bir kelime, her bir api'yi temel IP izleme köpeği veya diğer önlemleri uygulayarak çalıntı jetonunun / hizmetin kötüye kullanılmasının hasar kontrolünü sınırlamaya çalışabilirsiniz. Ancak kullanıcı hakkında kayıt okumak ve yazmak zorunda olduğunuz için bu pahalıdır ve sunucu yanıtınızı yavaşlatacaktır.
Bu yanıtların hiçbiri yenileme jetonlarının var olmasının temel nedenine ulaşmaz. Açıkçası, kimlik bilgilerinizi kimlik doğrulama sunucusuna göndererek her zaman yeni bir erişim belirteci / yenileme belirteci çifti alabilirsiniz;
Bu nedenle, yenileme kodunun tek amacı, tel üzerinden kimlik doğrulama hizmetine gönderilen istemci kimlik bilgilerinin kullanımını sınırlamaktır. Erişim belirteci ne kadar kısa olursa, istemci kimlik bilgilerinin yeni bir erişim belirteci elde etmek için o kadar sık kullanılması gerekir ve bu nedenle saldırganların istemci kimlik bilgilerinden ödün vermek için daha fazla fırsat olması gerekir (yine de bu çok zor olabilir) göndermek için asimetrik şifreleme kullanılıyor). Dolayısıyla, tek kullanımlık bir yenileme belirteciniz varsa, erişim kimliklerinin ttl'sini istemci kimlik bilgilerinden ödün vermeden keyfi olarak küçük yapabilirsiniz.
Biraz karışıklığı gidermek için, istemci sırrının ve çok farklı olan kullanıcı şifresinin rollerini anlamalısınız .
İstemci olan bir uygulamayı / web sitesi / program / ..., isteyen bir sunucu tarafından desteklenen kimlik doğrulaması bir kullanıcı bir üçüncü taraf kimlik hizmetini kullanarak. İstemci sırrı, hem bu istemci hem de kimlik doğrulama sunucusu tarafından bilinen (rastgele) bir dizedir. Bu sırrı kullanarak istemci, kimlik belirleme sunucusuyla kendini tanımlayarak erişim belirteçleri isteme yetkisi alabilir .
İlk erişim belirtecini almak ve belirtecini yenilemek için gerekli olan:
Ancak istemci aşağıdaki bilgileri kullanarak yenilenmiş erişim belirteci almak için :
Bu açıkça farkı gösterir: yenileme sırasında istemci, istemci sırrını kullanarak erişim belirteçlerini yenileme yetkisi alır ve böylece kullanıcı kimliği + parolası yerine yenileme belirtecini kullanarak kullanıcıyı yeniden doğrulayabilir . Bu, kullanıcının şifresini tekrar girmek zorunda kalmasını etkili bir şekilde önler.
Bu aynı zamanda, istemci kimliğini ve sırrını bilmediği için yenileme jetonunu kaybetmenin sorun olmadığını gösterir. Ayrıca müşteri kimliğini ve müşteri sırrını gizli tutmanın hayati önem taşıdığını da gösterir .
Bu cevap OAuth 2 standart gövde e-posta listesi aracılığıyla Justin Richer'dan. Bu onun izni ile gönderilir.
Yenileme belirtecinin ömrü (AS) yetkilendirme sunucusuna bağlıdır - süresi dolabilir, iptal edilebilir vb. Yenileme belirteci ile erişim belirteci arasındaki fark izleyicidir: yenileme belirteci yalnızca yetkilendirme sunucusuna geri döner, erişim belirteci (RS) kaynak sunucusuna gider.
Ayrıca, yalnızca bir erişim belirtecinin alınması kullanıcının oturum açtığı anlamına gelmez. Aslında, kullanıcı artık orada olmayabilir, bu da yenileme belirtecinin amaçlanan kullanım durumudur. Erişim belirtecini yenilemek size kullanıcı adına bir API'ya erişme izni verir, kullanıcının orada olup olmadığını size bildirmez.
OpenID Connect size bir erişim belirtecinden yalnızca kullanıcı bilgileri vermekle kalmaz, aynı zamanda bir kimlik belirteci de verir. Bu, AS veya RS'ye değil, istemciye yönelik ayrı bir veri parçasıdır. OIDC'de, yalnızca yeni bir kimlik jetonu alabiliyorsanız, protokol tarafından gerçekten "oturum açmış" birini düşünmelisiniz. Yenilemek yeterli olmayacaktır.
Daha fazla bilgi için lütfen http://oauth.net/articles/authentication/ adresini okuyun.
Müşteriler birçok açıdan tehlikeye girebilir. Örneğin bir cep telefonu klonlanabilir. Erişim belirtecinin süresinin dolması, istemcinin yetkilendirme sunucusunda yeniden kimlik doğrulaması yapmaya zorlandığı anlamına gelir. Yeniden kimlik doğrulama sırasında, yetkilendirme sunucusu diğer özellikleri kontrol edebilir (IOW uyarlanabilir erişim yönetimi gerçekleştirir).
Yenileme belirteçleri, istemcinin yalnızca yeniden kimlik doğrulamasına izin verir; burada yeniden yetkilendirme, kullanıcıyla birçok kişinin yapmayı tercih etmeyeceğini belirten bir iletişim kutusunu zorlar.
Yenileme jetonları, normal web sitelerinin bir saat kadar sonra kullanıcıları düzenli olarak yeniden doğrulamayı seçebileceği yere (ör. Bankacılık sitesi) uygundur. Çoğu sosyal web sitesi web kullanıcılarının kimlik doğrulamasını yapmadığı için şu anda çok kullanılmamaktadır, bu yüzden neden bir istemcinin kimlik doğrulaması yapılsın?
Neden access_token öğesini refresh_token olduğu sürece yenilemez ve refresh_token'e sahip olmazsınız?
Diğer insanların sağladığı harika yanıtlara ek olarak, yenileme jetonlarını kullanmanın ve iddialarla ilgili olmasının bir başka nedeni daha var.
Her belirteç, kullanıcı adından, rollerinden veya hak talebini oluşturan sağlayıcıdan herhangi bir şey içerebilecek hak talepleri içerir. Bir jeton yenilendiğinde bu hak talepleri güncellenir.
Jetonları daha sık yenilersek, kimlik hizmetlerimize daha fazla yük bindiririz, ancak daha doğru ve güncel iddialar alıyoruz.
BT'nin cevabını daha da basitleştirmek için: Genellikle kullanıcının kimlik bilgilerini tekrar yazmasını istemediğiniz, ancak yine de gücün izinleri iptal edebilmesini istediğinizde (yenileme kodunu iptal ederek) yenileme belirteçlerini kullanın.
Bir erişim belirtecini iptal edemezsiniz, yalnızca bir yenileme belirtecidir.
Bu cevap iki üst düzey geliştiricinin (John Brayton ve David Jennes) bir araya getirildi.
Yenileme belirteci kullanmanın ana nedeni saldırı yüzeyini azaltmaktır.
Diyelim ki yenileme tuşu yok ve bu örneği inceleyelim:
Bir binanın 80 kapısı vardır. Tüm kapılar aynı anahtarla açılır. Anahtar her 30 dakikada bir değişir. 30 dakikanın sonunda eski anahtarı anahtar üreticisine vermek ve yeni bir anahtar almak zorundayım.
Ben hacker'ım ve anahtarını alırsam, o zaman 30 dakikanın sonunda, bunu anahtar yapımcısına kurtaracağım ve yeni bir anahtar alacağım. Ben yapabileceksiniz sürekli anahtar değişen bakılmaksızın tüm kapıları açın.
Soru: 30 dakika boyunca, anahtara karşı kaç hackleme fırsatım oldu? Anahtarı her kullandığınızda 80 hackleme fırsatım oldu (bunu bir ağ isteği yapmak ve kendinizi tanımlamak için erişim belirtecini geçmek olarak düşünün). Yani bu 80X saldırı yüzeyi.
Şimdi aynı örneği inceleyelim ama bu sefer bir yenileme anahtarı olduğunu varsayalım.
Bir binanın 80 kapısı vardır. Tüm kapılar aynı anahtarla açılır. Anahtar her 30 dakikada bir değişir. Yeni bir anahtar almak için eski erişim kodunu geçemiyorum. Sadece yenileme anahtarını geçmeliyim.
Bilgisayar korsanıyım ve anahtarınızı alırsam, 30 dakika boyunca kullanabilirim, ancak 30 dakikanın sonunda anahtar üreticisine göndermenin hiçbir değeri yoktur. Eğer yaparsam, anahtar yapımcı sadece bu kötü yenileme jetonunu söylerdi. Saldırılarımı genişletebilmek için kuryeyi anahtar yapımcısına hacklemem gerekir. Kurye farklı bir anahtar var (bunu bir yenileme belirteci olarak düşünün).
Soru: 30 dakika boyunca, yenileme anahtarına karşı kaç hackleme fırsatım oldu? 80? Hayır. Sadece 1 hackleme fırsatım oldu. Kurye süre içinde anahtar yapımcısı ile iletişim kurar. Yani bu 1X saldırı yüzeyi. Anahtara karşı 80 hackleme fırsatım oldu, ancak 30 dakika sonra iyi değiller.
Bir sunucu kimlik bilgilerini ve (tipik olarak) bir JWT'nin imzalanmasını temel alarak bir erişim belirtecini doğrular.
Erişim belirteci sızıntısı kötü, ancak süresi dolduğunda saldırgan için artık kullanışlı değil. Yenileme belirteci sızıntısı çok daha kötüdür, ancak muhtemelen daha az olasıdır. (Bir yenileme belirtecinin sızma olasılığının, erişim belirtecinin sızıntı olasılığından çok daha düşük olup olmadığını sorgulamak için yer olduğunu düşünüyorum, ancak fikir bu.)
Önemli olan, erişim belirtecinin yaptığınız her isteğe eklenmesi, ancak bir yenileme belirtecinin yalnızca yenileme akışı sırasında kullanılmasıdır. Bir MITM'nin belirteci görme şansı daha azdır
Frekans bir saldırgana yardımcı olur. SSL'deki kalp gibi potansiyel güvenlik kusurları, istemcideki potansiyel güvenlik kusurları ve sunucudaki potansiyel güvenlik kusurları sızıntıyı mümkün kılar.
Ayrıca, yetkilendirme sunucusu diğer istemci isteklerini işleyen uygulama sunucusundan ayrıysa, uygulama sunucusu hiçbir zaman yenileme jetonlarını görmez. Yalnızca çok daha uzun süre yaşamayan erişim belirteçlerini görecektir.
Bölümlendirme güvenlik için iyidir.
Son fakat en az değil, bu harika cevabı gör
Hangi yenileme simgesi DEĞİLDİR?
Yenileme jetonları aracılığıyla erişim düzeyini güncelleme / iptal etme yeteneği, yenileme jetonlarını kullanmayı seçmenin bir yan ürünüdür, aksi takdirde bağımsız bir erişim jetonu iptal edilebilir veya süresi dolduğunda ve kullanıcılar yeni bir jeton aldığında erişim seviyesi değiştirilebilir.
Sonuncuyu access_tokençok uzun sürdüğünüzü ve varsayalım refresh_token, bu yüzden bir günde hacker bunu alıraccess_token ve tüm korunan kaynaklara erişebilir!
Eğer varsa refresh_token, access_token's canlı süresi kısa, bu yüzden hacker kesmek zor access_tokençünkü kısa bir süre sonra geçersiz olacaktır.
Access_tokensadece hacker refresh_tokendeğil aynı zamanda client_idve tarafından da geri alınabilir client_secret.
Yenileme belirteci Yetkilendirme sunucusu tarafından korunurken. Erişim jetonu bağımsızdır, böylece kaynak sunucusu onu saklamadan doğrulayabilir, bu da doğrulama durumunda geri alma çabasını azaltır. Tartışmada eksik başka bir nokta rfc6749 gelen # sayfa-55
"Örneğin, yetkilendirme sunucusu, her erişim belirteci yenileme yanıtıyla yeni bir yenileme belirtecinin verildiği yenileme belirteci döndürmeyi kullanabilir. Önceki yenileme belirteci geçersiz kılınmış, ancak yetkilendirme sunucusu tarafından alıkonulmuşsa. hem saldırgan hem de yasal istemci, bunlardan biri, yetkilendirme sunucusunu ihlali bildiren geçersiz kılınmış bir yenileme belirteci sunacak. "
Yenileme belirtecini kullanmanın tüm amacı, saldırgan bir şekilde yenileme belirteci, istemci kimliği ve gizli kombinasyon almayı başarsa bile. Sonraki çağrılarla, her yenileme talebinin yeni erişim belirteci ve yenileme belirteciyle sonuçlanması durumunda saldırgandan yeni erişim belirteci almak için izlenebilir.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Her kullanıcının bir veya daha fazla role ve her rolün bir veya daha fazla erişim ayrıcalığına bağlı olduğu bir sistemi ele alalım. Bu bilgiler daha iyi API performansı için önbelleğe alınabilir. Ancak daha sonra, kullanıcı ve rol yapılandırmalarında değişiklikler olabilir (örneğin, yeni erişim verilebilir veya geçerli erişim iptal edilebilir) ve bunlar önbelleğe yansıtılmalıdır.
Bu amaçla erişim ve yenileme jetonlarını kullanabiliriz. Bir API erişim belirteciyle çağrıldığında, kaynak sunucu önbellek erişim haklarını kontrol eder. Herhangi bir yeni erişim izni varsa, hemen yansıtılmaz. Erişim belirtecinin süresi dolduğunda (örneğin 30 dakika içinde) ve istemci yeni bir erişim belirteci oluşturmak için yenileme belirtecini kullandığında, önbellek DB'den güncellenen kullanıcı erişim hakkı bilgileriyle güncelleştirilebilir.
Başka bir deyişle, erişim belirteçlerini kullanarak her API çağrısından pahalı işlemleri, yenileme belirteci kullanarak erişim belirteci oluşturma olayına taşıyabiliriz.
İlk olarak, istemci yetkilendirme hibesi vererek yetkilendirme sunucusuyla kimlik doğrulaması yapar.
Sonra istemci, erişim belirteci vererek kaynak sunucusundan korunan kaynak için istekte bulunur.
Kaynak sunucu erişim kodunu doğrular ve korunan kaynağı sağlar.
İstemci, erişim sunucusunu onayladığı ve geçerliyse isteği sunduğu erişim belirteci vererek, korunan kaynak isteğini kaynak sunucuya yapar. Bu adım, erişim belirtecinin süresi doluncaya kadar yinelenmeye devam eder.
Erişim belirtecinin süresi dolarsa, istemci yetkilendirme sunucusuyla kimlik doğrulaması yapar ve yenileme belirteci sağlayarak yeni bir erişim belirteci ister. Erişim belirteci geçersizse, kaynak sunucu istemciye geçersiz belirteç hata yanıtını geri gönderir.
İstemci, yenileme belirteci vererek yetkilendirme sunucusuyla kimlik doğrulaması yapar.
Yetkilendirme sunucusu daha sonra istemcinin kimliğini doğrulayarak yenileme belirtecini doğrular ve geçerliyse yeni bir erişim belirteci verir.
access token + refresh token?