Mục 4.2 của dự thảo giao thức OAuth 2.0 chỉ ra rằng một máy chủ ủy quyền có thể trả về cả access_token(được sử dụng để xác thực chính mình bằng tài nguyên) cũng như refresh_token, được sử dụng hoàn toàn để tạo mới access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Tại sao có cả hai? Tại sao không chỉ làm cho access_tokencuối cùng miễn là refresh_tokenvà không có một refresh_token?
Câu trả lời:
Ý tưởng của mã thông báo làm mới là nếu mã thông báo truy cập bị xâm phạm, vì nó tồn tại trong thời gian ngắn, kẻ tấn công có một cửa sổ giới hạn để lạm dụng nó.
Làm mới mã thông báo, nếu bị xâm phạm, sẽ vô dụng vì kẻ tấn công yêu cầu id khách hàng và bí mật ngoài mã thông báo làm mới để có được mã thông báo truy cập.
Phải nói rằng , bởi vì mọi cuộc gọi đến cả máy chủ ủy quyền và máy chủ tài nguyên đều được thực hiện qua SSL - bao gồm cả id khách hàng ban đầu và bí mật khi họ yêu cầu mã thông báo truy cập / làm mới - tôi không chắc chắn về cách mã thông báo truy cập nữa " có thể thỏa hiệp "hơn so với kết hợp mã thông báo làm mới và clientid / bí mật tồn tại lâu dài.
Tất nhiên điều này khác với việc triển khai khi bạn không kiểm soát cả máy chủ ủy quyền và máy chủ tài nguyên.
Đây là một chủ đề hay nói về việc sử dụng mã thông báo làm mới: Lưu trữ OAuth .
Một trích dẫn ở trên, nói về mục đích bảo mật của mã thông báo làm mới:
Làm mới mã thông báo ... giảm thiểu rủi ro rò rỉ access_token tồn tại lâu dài (truy vấn param trong tệp nhật ký trên máy chủ tài nguyên không an toàn, ứng dụng máy chủ tài nguyên mã hóa beta hoặc mã hóa kém, ứng dụng JS SDK trên trang web không https đặt một access_token cookie, v.v.)
Liên kết đến thảo luận, được cung cấp bởi Catchdave, có một điểm hợp lệ khác (bản gốc, liên kết chết) được tạo bởi Dick Hardt, mà tôi tin là đáng để đề cập ở đây ngoài những gì đã được viết ở trên:
Hồi ức của tôi về các mã thông báo làm mới là để bảo mật và thu hồi. <...>
thu hồi: nếu mã thông báo truy cập độc lập, ủy quyền có thể bị thu hồi bằng cách không phát hành mã thông báo truy cập mới. Tài nguyên không cần truy vấn máy chủ ủy quyền để xem mã thông báo truy cập có hợp lệ hay không. Điều này giúp đơn giản hóa xác thực mã thông báo truy cập và giúp dễ dàng mở rộng và hỗ trợ nhiều máy chủ ủy quyền. Có một cửa sổ thời gian khi mã thông báo truy cập hợp lệ, nhưng ủy quyền bị thu hồi.
Thật vậy, trong trường hợp Máy chủ tài nguyên và Máy chủ ủy quyền là cùng một thực thể và trong đó kết nối giữa người dùng và một trong hai người đó (thường) an toàn như nhau, sẽ không có nhiều ý nghĩa để giữ mã thông báo làm mới tách biệt với mã thông báo truy cập.
Mặc dù, như đã đề cập trong đoạn trích dẫn, một vai trò khác của mã thông báo làm mới là đảm bảo mã thông báo truy cập có thể bị thu hồi bất cứ lúc nào bởi Người dùng (chẳng hạn như thông qua giao diện web trong hồ sơ của họ) trong khi vẫn giữ cho hệ thống có thể mở rộng cùng lúc .
Nói chung, mã thông báo có thể là số nhận dạng ngẫu nhiên trỏ đến bản ghi cụ thể trong cơ sở dữ liệu của Máy chủ hoặc chúng có thể chứa tất cả thông tin trong chính chúng ( ví dụ , thông tin này phải được ký, với MAC chẳng hạn).
Làm thế nào hệ thống với mã thông báo truy cập lâu dài nên hoạt động
Máy chủ cho phép Khách hàng truy cập vào dữ liệu của Người dùng trong một phạm vi được xác định trước bằng cách phát hành mã thông báo. Vì chúng tôi muốn giữ mã thông báo có thể hủy bỏ, chúng tôi phải lưu trữ trong cơ sở dữ liệu mã thông báo cùng với cờ "bị thu hồi" được đặt hoặc hủy đặt (nếu không, bạn sẽ làm thế nào với mã thông báo tự chứa?) Cơ sở dữ liệu có thể chứa nhiều như len(users) x len(registered clients) x len(scopes combination)các bản ghi . Mỗi yêu cầu API sau đó phải nhấn cơ sở dữ liệu. Mặc dù việc truy vấn cơ sở dữ liệu như vậy thực hiện O (1) khá đơn giản, nhưng điểm lỗi duy nhất có thể có tác động tiêu cực đến khả năng mở rộng và hiệu suất của hệ thống.
Cách hệ thống với mã thông báo làm mới tồn tại lâu và mã thông báo truy cập ngắn hạn nên hoạt động
Ở đây chúng tôi phát hành hai khóa: mã thông báo làm mới ngẫu nhiên với bản ghi tương ứng trong cơ sở dữ liệu và mã thông báo truy cập độc lập đã ký, trong số đó có trường dấu thời gian hết hạn.
Vì mã thông báo truy cập độc lập, chúng tôi hoàn toàn không phải truy cập cơ sở dữ liệu để kiểm tra tính hợp lệ của nó. Tất cả chúng ta phải làm là giải mã mã thông báo và xác thực chữ ký và dấu thời gian.
Tuy nhiên, chúng tôi vẫn phải giữ cơ sở dữ liệu của các mã thông báo làm mới, nhưng số lượng yêu cầu đối với cơ sở dữ liệu này thường được xác định theo tuổi thọ của mã thông báo truy cập (tuổi thọ càng dài, tốc độ truy cập càng thấp).
Để thu hồi quyền truy cập của Khách hàng từ một Người dùng cụ thể, chúng tôi nên đánh dấu mã thông báo làm mới tương ứng là "đã thu hồi" (hoặc xóa hoàn toàn) và ngừng phát hành mã thông báo truy cập mới. Mặc dù rõ ràng là có một cửa sổ trong đó mã thông báo làm mới đã bị thu hồi, nhưng mã thông báo truy cập của nó vẫn có thể hợp lệ.
Đánh đổi
Làm mới mã thông báo loại bỏ một phần SPoF (Điểm lỗi duy nhất) của cơ sở dữ liệu Mã thông báo truy cập, tuy nhiên chúng có một số nhược điểm rõ ràng.
Cửa sổ". Khung thời gian giữa các sự kiện "người dùng thu hồi quyền truy cập" và "quyền truy cập được đảm bảo sẽ bị thu hồi".
Sự phức tạp của logic Client.
không có mã thông báo làm mới
với mã thông báo làm mới
Tôi hy vọng câu trả lời này có ý nghĩa và giúp ai đó đưa ra quyết định chu đáo hơn. Tôi cũng muốn lưu ý rằng một số nhà cung cấp OAuth2 nổi tiếng, bao gồm github và giao thức áp dụng giao thức mà không cần làm mới mã thông báo và có vẻ hài lòng với điều đó.
Bất chấp tất cả các câu trả lời tuyệt vời ở trên, tôi với tư cách là một sinh viên thạc sĩ bảo mật và lập trình viên trước đây làm việc tại eBay khi tôi xem xét việc bảo vệ và lừa đảo người mua, có thể nói tách biệt mã thông báo truy cập và mã thông báo làm mới có sự cân bằng tốt nhất giữa người dùng quấy rối dùng tên người dùng thường xuyên / nhập mật khẩu và giữ quyền trong tay để thu hồi quyền truy cập vào khả năng lạm dụng dịch vụ của bạn.
Hãy nghĩ về một kịch bản như thế này. Bạn cấp cho người dùng mã thông báo truy cập 3600 giây và làm mới mã thông báo lâu hơn một ngày.
Người dùng là một người dùng tốt , anh ta ở nhà và bật / tắt trang web của bạn mua sắm và tìm kiếm trên iPhone của anh ta. Địa chỉ IP của anh ấy không thay đổi và tải rất thấp trên máy chủ của bạn. Thích 3-5 trang yêu cầu mỗi phút. Khi hết 3600 giây trên mã thông báo truy cập, anh ta yêu cầu một mã mới với mã thông báo làm mới. Chúng tôi, về phía máy chủ, kiểm tra lịch sử hoạt động và địa chỉ IP của anh ấy, nghĩ rằng anh ấy là một con người và tự hành xử. Chúng tôi cấp cho anh ấy mã thông báo truy cập mới để tiếp tục sử dụng dịch vụ của chúng tôi. Người dùng sẽ không cần nhập lại tên người dùng / mật khẩu cho đến khi anh ta đạt được vòng đời của mã thông báo làm mới một ngày.
Người dùng là một người dùng bất cẩn . Anh ta sống ở New York, Hoa Kỳ và bị tắt chương trình virus và bị tin tặc tấn công ở Ba Lan . Khi tin tặc có mã thông báo truy cập và làm mới mã thông báo, anh ta cố gắng mạo danh người dùng và sử dụng dịch vụ của chúng tôi. Nhưng sau khi mã thông báo truy cập ngắn hạn hết hạn, khi tin tặc cố gắng làm mới mã thông báo truy cập, chúng tôi, trên máy chủ, đã nhận thấy sự thay đổi đáng kể về IP trong lịch sử hành vi người dùng (hey, anh chàng này đăng nhập ở Mỹ và hiện đang làm mới quyền truy cập ở Ba Lan chỉ sau 3600s ???). Chúng tôi chấm dứt quá trình làm mới, vô hiệu hóa chính mã thông báo làm mới và nhắc nhập lại tên người dùng / mật khẩu.
Người dùng là một người dùng độc hại . Anh ta có ý định lạm dụng dịch vụ của chúng tôi bằng cách gọi 1000 lần API của chúng tôi mỗi phút bằng robot. Anh ta có thể làm tốt như vậy cho đến 3600 giây sau, khi anh ta cố gắng làm mới mã thông báo truy cập, chúng tôi nhận thấy hành vi của anh ta và nghĩ rằng anh ta có thể không phải là một con người. Chúng tôi từ chối và chấm dứt quá trình làm mới và yêu cầu anh ta nhập lại tên người dùng / mật khẩu. Điều này có khả năng phá vỡ dòng chảy tự động của robot của anh ấy. Ít nhất là làm cho anh ta khó chịu.
Bạn có thể thấy mã thông báo làm mới đã hoạt động hoàn hảo khi chúng tôi cố gắng cân bằng công việc, trải nghiệm người dùng và rủi ro tiềm ẩn của mã thông báo bị đánh cắp. Con chó canh gác của bạn ở phía máy chủ có thể kiểm tra nhiều hơn thay đổi IP, tần suất của các cuộc gọi api để xác định xem người dùng có phải là người dùng tốt hay không.
Một từ khác là bạn cũng có thể cố gắng hạn chế kiểm soát thiệt hại của mã thông báo bị đánh cắp / lạm dụng dịch vụ bằng cách thực hiện trên mỗi cuộc gọi api của con chó canh gác IP cơ bản hoặc bất kỳ biện pháp nào khác. Nhưng điều này rất tốn kém khi bạn phải đọc và viết hồ sơ về người dùng và sẽ làm chậm phản ứng máy chủ của bạn.
Cả hai câu trả lời này đều không có lý do cốt lõi để làm mới mã thông báo. Rõ ràng, bạn luôn có thể nhận được cặp mã thông báo truy cập / mã thông báo mới bằng cách gửi thông tin xác thực ứng dụng khách của bạn đến máy chủ xác thực - đó là cách bạn có được chúng ở vị trí đầu tiên.
Vì vậy, mục đích duy nhất của mã thông báo làm mới là để hạn chế việc sử dụng thông tin đăng nhập của khách hàng được gửi qua mạng đến dịch vụ xác thực. Ttl của mã thông báo truy cập càng ngắn, thông tin khách hàng sẽ càng phải được sử dụng để có được mã thông báo truy cập mới và do đó, càng nhiều cơ hội kẻ tấn công phải thỏa hiệp thông tin đăng nhập của khách hàng (mặc dù điều này có thể rất khó khăn nếu mã hóa bất đối xứng đang được sử dụng để gửi chúng). Vì vậy, nếu bạn có mã thông báo làm mới sử dụng một lần, bạn có thể đặt ttl của mã thông báo truy cập nhỏ tùy ý mà không ảnh hưởng đến thông tin đăng nhập của khách hàng.
Để làm sáng tỏ một số nhầm lẫn, bạn phải hiểu vai trò của bí mật khách hàng và mật khẩu người dùng , rất khác nhau.
Các khách hàng là một ứng dụng / trang web / chương trình / ..., được hỗ trợ bởi một máy chủ, mà muốn xác thực một người dùng bằng cách sử dụng một dịch vụ xác thực của bên thứ ba. Bí mật máy khách là một chuỗi (ngẫu nhiên) được cả máy khách này và máy chủ xác thực biết. Sử dụng bí mật này, khách hàng có thể nhận dạng chính nó với máy chủ xác thực, nhận ủy quyền để yêu cầu mã thông báo truy cập.
Để nhận mã thông báo truy cập ban đầu và mã thông báo làm mới, điều bắt buộc là:
Để có được mã thông báo truy cập được làm mới tuy nhiên khách hàng sử dụng thông tin sau:
Điều này cho thấy rõ sự khác biệt: khi làm mới, ứng dụng khách nhận được ủy quyền để làm mới mã thông báo truy cập bằng cách sử dụng bí mật ứng dụng khách của mình và do đó có thể xác thực lại người dùng bằng mã thông báo làm mới thay vì mật khẩu ID + của người dùng. Điều này có hiệu quả ngăn người dùng khỏi phải nhập lại mật khẩu của mình.
Điều này cũng cho thấy việc mất mã thông báo làm mới không có vấn đề gì vì ID khách hàng và bí mật không được biết. Nó cũng cho thấy việc giữ bí mật ID khách hàng và bí mật của khách hàng là điều tối quan trọng .
Câu trả lời này là của Justin Richer thông qua danh sách email cơ thể tiêu chuẩn OAuth 2. Điều này được đăng với sự cho phép của mình.
Tuổi thọ của mã thông báo làm mới tùy thuộc vào máy chủ ủy quyền (AS) - chúng có thể hết hạn, bị thu hồi, v.v. Sự khác biệt giữa mã thông báo làm mới và mã thông báo truy cập là đối tượng: mã thông báo làm mới chỉ quay lại máy chủ ủy quyền, mã thông báo truy cập đến máy chủ tài nguyên (RS).
Ngoài ra, chỉ nhận được mã thông báo truy cập không có nghĩa là người dùng đã đăng nhập. Trên thực tế, người dùng thậm chí có thể không còn ở đó nữa, đây thực sự là trường hợp sử dụng dự định của mã thông báo làm mới. Làm mới mã thông báo truy cập sẽ cung cấp cho bạn quyền truy cập vào API thay mặt người dùng, nó sẽ không cho bạn biết nếu người dùng ở đó.
OpenID Connect không chỉ cung cấp cho bạn thông tin người dùng từ mã thông báo truy cập, nó cũng cung cấp cho bạn mã thông báo ID. Đây là một phần dữ liệu riêng biệt hướng vào chính máy khách, không phải AS hoặc RS. Trong OIDC, bạn chỉ nên xem xét một người nào đó thực sự đã đăng nhập vào giao thức bằng giao thức nếu bạn có thể nhận được mã thông báo ID mới. Làm mới nó không có khả năng là đủ.
Để biết thêm thông tin xin vui lòng đọc http://oauth.net/articles/authentication/
Khách hàng có thể bị xâm phạm theo nhiều cách. Ví dụ, một điện thoại di động có thể được nhân bản. Có một mã thông báo truy cập hết hạn có nghĩa là khách hàng buộc phải xác thực lại cho máy chủ ủy quyền. Trong quá trình xác thực lại, máy chủ ủy quyền có thể kiểm tra các đặc điểm khác (IOW thực hiện quản lý truy cập thích ứng).
Làm mới mã thông báo cho phép khách hàng chỉ xác thực lại, khi ủy quyền lại buộc một hộp thoại với người dùng mà nhiều người cho biết họ không muốn làm.
Làm mới mã thông báo phù hợp về cơ bản ở cùng một nơi mà các trang web bình thường có thể chọn định kỳ xác thực lại người dùng sau một giờ hoặc lâu hơn (ví dụ: trang web ngân hàng). Hiện tại nó không được sử dụng nhiều vì hầu hết các trang web xã hội không xác thực lại người dùng web, vậy tại sao họ lại xác thực lại một khách hàng?
Tại sao không làm cho access_token tồn tại lâu như refresh_token và không có refresh_token?
Ngoài những câu trả lời tuyệt vời mà những người khác đã cung cấp, còn có một lý do khác tại sao sẽ sử dụng mã thông báo làm mới và nó có liên quan đến khiếu nại.
Mỗi mã thông báo chứa các khiếu nại có thể bao gồm mọi thứ từ tên người dùng, vai trò của họ hoặc nhà cung cấp đã tạo ra khiếu nại. Khi mã thông báo được làm mới, các khiếu nại này được cập nhật.
Nếu chúng tôi làm mới mã thông báo thường xuyên hơn, rõ ràng chúng tôi đang gây căng thẳng hơn cho các dịch vụ nhận dạng của mình, tuy nhiên chúng tôi sẽ nhận được các yêu cầu chính xác và cập nhật hơn.
Để đơn giản hóa hơn nữa câu trả lời của BT: Sử dụng mã thông báo làm mới khi bạn thường không muốn người dùng phải nhập lại thông tin đăng nhập, nhưng vẫn muốn sức mạnh có thể thu hồi quyền (bằng cách thu hồi mã thông báo làm mới)
Bạn không thể thu hồi mã thông báo truy cập, chỉ một mã thông báo làm mới.
Câu trả lời này đã được đặt ra cùng với sự giúp đỡ của hai nhà phát triển cao cấp (John Brayton và David Jennes).
Lý do chính để sử dụng mã thông báo làm mới là để giảm bề mặt tấn công.
Giả sử không có khóa làm mới và hãy xem ví dụ này:
Một tòa nhà có 80 cửa. Tất cả các cửa được mở với cùng một chìa khóa. Phím thay đổi cứ sau 30 phút. Hết 30 phút tôi phải đưa chìa khóa cũ cho thợ sửa khóa và lấy chìa khóa mới.
Nếu tôi là hacker và nhận được chìa khóa của bạn, thì vào cuối 30 phút, tôi sẽ chuyển phát nhanh đến người làm chìa khóa và nhận một khóa mới. Tôi sẽ có thể liên tục mở tất cả các cửa bất kể thay đổi chìa khóa.
Câu hỏi: Trong 30 phút, tôi có bao nhiêu cơ hội hack đối với chìa khóa? Tôi đã có 80 cơ hội hack, mỗi lần bạn sử dụng khóa (hãy nghĩ rằng điều này là thực hiện một yêu cầu mạng và chuyển mã thông báo truy cập để nhận dạng chính bạn). Vì vậy, đó là bề mặt tấn công 80X.
Bây giờ chúng ta hãy đi qua ví dụ tương tự nhưng lần này hãy giả sử có một khóa làm mới.
Một tòa nhà có 80 cửa. Tất cả các cửa được mở với cùng một chìa khóa. Phím thay đổi cứ sau 30 phút. Để có khóa mới, tôi không thể chuyển mã thông báo truy cập cũ. Tôi chỉ phải vượt qua khóa làm mới.
Nếu tôi là hacker và nhận được chìa khóa của bạn, tôi có thể sử dụng nó trong 30 phút, nhưng vào cuối 30 phút gửi nó cho người làm chìa khóa không có giá trị. Nếu tôi làm như vậy, thì người làm chìa khóa sẽ chỉ nói mã thông báo làm mới xấu này. Để có thể mở rộng bản hack của mình, tôi sẽ phải hack chuyển phát nhanh cho người làm chìa khóa. Chuyển phát nhanh có một khóa riêng biệt (nghĩ về điều này như một mã thông báo làm mới).
Câu hỏi: Trong 30 phút, tôi đã có bao nhiêu cơ hội hack đối với khóa làm mới? 80? Không. Tôi chỉ có 1 cơ hội hack. Trong thời gian chuyển phát nhanh liên lạc với thợ làm chìa khóa. Vì vậy, đó là bề mặt tấn công 1X. Tôi đã có 80 cơ hội hack chống lại chìa khóa, nhưng chúng không tốt sau 30 phút.
Một máy chủ sẽ xác minh mã thông báo truy cập dựa trên thông tin đăng nhập và ký (thường là) JWT.
Một rò rỉ mã thông báo truy cập là xấu, nhưng một khi nó hết hạn, nó không còn hữu ích cho kẻ tấn công. Một rò rỉ mã thông báo làm mới là tồi tệ hơn nhiều, nhưng có lẽ nó ít có khả năng. (Tôi nghĩ có thể đặt câu hỏi liệu khả năng rò rỉ mã thông báo làm mới có thấp hơn nhiều so với rò rỉ mã thông báo truy cập hay không, nhưng đó là ý tưởng.)
Điểm đáng chú ý là mã thông báo truy cập được thêm vào mọi yêu cầu bạn thực hiện, trong khi mã thông báo làm mới chỉ được sử dụng trong luồng làm mới Vì vậy, ít có khả năng MITM nhìn thấy mã thông báo
Tần suất giúp kẻ tấn công. Đau lòng bảo mật tiềm năng giống như trong SSL, các lỗi bảo mật tiềm ẩn trong máy khách và các lỗi bảo mật tiềm ẩn trong máy chủ đều khiến việc rò rỉ có thể xảy ra.
Ngoài ra, nếu máy chủ ủy quyền tách biệt với máy chủ ứng dụng xử lý các yêu cầu máy khách khác thì máy chủ ứng dụng đó sẽ không bao giờ thấy mã thông báo làm mới. Nó sẽ chỉ thấy các mã thông báo truy cập sẽ không tồn tại lâu hơn nữa.
Khoang là tốt cho an ninh.
Cuối cùng nhưng không kém phần quan thấy câu trả lời tuyệt vời này
Mã thông báo làm mới nào KHÔNG phải là về?
Khả năng cập nhật / thu hồi cấp độ truy cập thông qua mã thông báo làm mới là sản phẩm phụ của việc chọn sử dụng mã thông báo làm mới, nếu không, mã thông báo truy cập độc lập có thể bị thu hồi hoặc sửa đổi cấp truy cập khi hết hạn và người dùng nhận được mã thông báo mới
Giả sử bạn thực hiện access_tokenlần cuối rất lâu và không có refresh_token, vì vậy trong một ngày, hacker có được điều nàyaccess_token và anh ta có thể truy cập tất cả các tài nguyên được bảo vệ!
Nhưng nếu bạn có refresh_token, access_tokenthời gian trực tiếp rất ngắn, do đó, hacker khó có thể hack bạn access_tokenvì nó sẽ không hợp lệ sau một khoảng thời gian ngắn.
Access_tokenchỉ có thể được truy xuất trở lại bằng cách sử dụng không chỉ refresh_tokenmà còn bởi client_idvà client_secret, điều mà hacker không có.
Trong khi mã thông báo làm mới được giữ lại bởi máy chủ Ủy quyền. Mã thông báo truy cập được khép kín để máy chủ tài nguyên có thể xác minh nó mà không lưu trữ nó giúp tiết kiệm công sức truy xuất trong trường hợp xác thực. Một điểm khác trong cuộc thảo luận là từ rfc6749 # page-55
"Ví dụ: máy chủ ủy quyền có thể sử dụng vòng quay mã thông báo làm mới, trong đó mã thông báo làm mới được phát hành với mỗi phản hồi làm mới mã thông báo truy cập. Mã thông báo làm mới trước đó bị vô hiệu nhưng được giữ lại bởi máy chủ ủy quyền. Nếu mã thông báo làm mới bị xâm phạm và sau đó được sử dụng bởi cả kẻ tấn công và khách hàng hợp pháp, một trong số họ sẽ đưa ra một mã thông báo làm mới không hợp lệ, sẽ thông báo cho máy chủ ủy quyền về vi phạm. "
Tôi nghĩ rằng toàn bộ quan điểm của việc sử dụng mã thông báo làm mới là ngay cả khi kẻ tấn công bằng cách nào đó quản lý để nhận mã thông báo làm mới, ID khách hàng và kết hợp bí mật. Với các cuộc gọi tiếp theo để nhận mã thông báo truy cập mới từ kẻ tấn công có thể được theo dõi trong trường hợp nếu mọi yêu cầu làm mới đều dẫn đến mã thông báo truy cập mới và mã thông báo làm mới.
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.
Hãy xem xét một hệ thống trong đó mỗi người dùng được liên kết với một hoặc nhiều vai trò và mỗi vai trò được liên kết với một hoặc nhiều đặc quyền truy cập. Thông tin này có thể được lưu trữ để có hiệu suất API tốt hơn. Nhưng sau đó, có thể có những thay đổi trong cấu hình người dùng và vai trò (ví dụ: quyền truy cập mới có thể được cấp hoặc quyền truy cập hiện tại có thể bị thu hồi) và những điều này sẽ được phản ánh trong bộ đệm.
Chúng tôi có thể sử dụng mã thông báo truy cập và làm mới cho mục đích đó. Khi một API được gọi với mã thông báo truy cập, máy chủ tài nguyên sẽ kiểm tra bộ đệm để tìm quyền truy cập. NẾU có bất kỳ cấp quyền truy cập mới, nó không được phản ánh ngay lập tức. Khi mã thông báo truy cập hết hạn (giả sử trong 30 phút) và máy khách sử dụng mã thông báo làm mới để tạo mã thông báo truy cập mới, bộ đệm có thể được cập nhật với thông tin quyền truy cập của người dùng được cập nhật từ DB.
Nói cách khác, chúng ta có thể di chuyển các hoạt động đắt tiền từ mọi lệnh gọi API bằng cách sử dụng mã thông báo truy cập đến sự kiện tạo mã thông báo truy cập bằng cách sử dụng mã thông báo làm mới.
Đầu tiên, khách hàng xác thực với máy chủ ủy quyền bằng cách cấp quyền.
Sau đó, máy khách yêu cầu máy chủ tài nguyên cho tài nguyên được bảo vệ bằng cách cấp mã thông báo truy cập.
Máy chủ tài nguyên xác nhận mã thông báo truy cập và cung cấp tài nguyên được bảo vệ.
Máy khách thực hiện yêu cầu tài nguyên được bảo vệ cho máy chủ tài nguyên bằng cách cấp mã thông báo truy cập, nơi máy chủ tài nguyên xác thực nó và phục vụ yêu cầu, nếu hợp lệ. Bước này tiếp tục lặp lại cho đến khi mã thông báo truy cập hết hạn.
Nếu mã thông báo truy cập hết hạn, máy khách sẽ xác thực với máy chủ ủy quyền và yêu cầu mã thông báo truy cập mới bằng cách cung cấp mã thông báo làm mới. Nếu mã thông báo truy cập không hợp lệ, máy chủ tài nguyên sẽ gửi lại phản hồi lỗi mã thông báo không hợp lệ cho máy khách.
Máy khách xác thực với máy chủ ủy quyền bằng cách cấp mã thông báo làm mới.
Sau đó, máy chủ ủy quyền xác thực mã thông báo làm mới bằng cách xác thực ứng dụng khách và cấp mã thông báo truy cập mới, nếu nó hợp lệ.
access token + refresh tokengì?