Tôi có thể/nên làm mới mã thông báo OAuth2 với mọi yêu cầu trong bảo mật mùa xuân

Question

Chúng tôi sử dụng trợ cấp mật khẩu tên người dùng để kết nối máy khách JS của chúng tôi với máy chủ REST của chúng tôi. Theo cách mà mã thông báo được trả về bởi oauth/token là phiên của chúng tôi, vì nó cho phép truy cập vào chương trình phụ trợ trong một thời gian giới hạn.

Chúng tôi muốn làm mới phiên/mã thông báo đó mỗi lần chúng tôi đưa ra yêu cầu cho chương trình phụ trợ bằng mã thông báo.

Tôi biết có mã thông báo làm mới này do máy chủ cấp và tôi có thể sử dụng nó để làm mới mã thông báo sau khi hết hạn.

Điều này là: Tôi không muốn làm cho nó trở thành trách nhiệm của khách hàng để bắt ngoại lệ hết hạn mã thông báo và xác thực lại hoặc lên lịch làm mới trước khi hết hạn mã thông báo. Tôi muốn mã thông báo tự làm mới cho đến khi nó không được sử dụng nữa trong một khoảng thời gian giới hạn - giống như một phiên. (Tôi cũng không muốn phát hành yêu cầu làm mới với mọi yêu cầu "dữ liệu", mặc dù tôi nghĩ rằng tôi nhớ đọc, mã thông báo làm mới chỉ hợp lệ một lần ..?!)

Có cách nào để làm điều đó không vào mùa xuân bảo mật hoặc tôi sẽ phải xây dựng một số tùy chỉnh thực hiện các cửa hàng mã thông báo hoặc bất cứ phần nào tôi chọn?

Vì tôi thực sự không thể tìm thấy câu trả lời (do đó bài đăng) Tôi nghĩ: Có thể không phải là điều khôn ngoan để làm điều này, mặc dù tôi không thể nghĩ tại sao. Nếu tôi có thể ăn cắp mã thông báo, tôi cũng có thể lấy cắp mã thông báo làm mới. Vì vậy, tôi đoán tôi không thực sự nhìn thấy điểm việc có một dấu hiệu làm mới ở nơi đầu tiên ..

EDIT

Đáp lại câu trả lời Luke Taylor tôi sẽ clearify trường hợp sử dụng của chúng tôi.

• Chúng tôi có máy chủ REST chứa dữ liệu ứng dụng như người. nhưng cũng cung cấp quyền truy cập vào quản lý nội dung của chúng tôi và cho phép khách hàng đăng lên facebook. Nó đóng gói logic ứng dụng và lưu trữ dữ liệu
• Chúng tôi có một ứng dụng khách chính thức đã có sẵn lớp bảo mật và justs truy cập dữ liệu trên máy chủ REST của chúng tôi thông qua luồng thông tin khách hàng. Ai có thể làm những gì được quyết định ở phía khách hàng
• Chúng tôi có một số ứng dụng vừa và nhỏ như ứng dụng liên hệ trên facebook truy cập dữ liệu trên máy chủ REST cũng sử dụng thông tin đăng nhập của khách hàng
• Hiện tại chúng tôi đang phát triển ứng dụng khách javascript sẽ truy cập vào lớp REST để làm tất cả những thứ mà ứng dụng khách lớn thực hiện nhưng cũng cần cung cấp một phương tiện để xác thực người dùng cá nhân và cho phép nhiều thuê nhà. Do đó, ứng dụng khách mới này sử dụng trợ cấp tên người dùng-mật khẩu để xác thực và bảo mật mức phương thức để ủy quyền cho người dùng

Vì vậy, chúng tôi có một máy chủ REST cần truy cập đầy đủ vào ứng dụng đáng tin cậy của chúng tôi cùng một máy chủ đó cần cung cấp quyền truy cập cho người dùng ứng dụng khách JavaScript đa nhiệm mới của chúng tôi. Trong sản xuất, chúng tôi sẽ có một vài máy chủ REST với cơ sở dữ liệu riêng của mình nhưng lõi sẽ luôn giống nhau, vì vậy trong lý thuyết một máy chủ sẽ có thể xử lý tất cả.

Answer 1

Tôi muốn token để làm mới bản thân cho đến khi nó không được sử dụng nữa cho một số lượng hạn chế về thời gian - giống như một phiên

này không thực sự có ý nghĩa (trong một bối cảnh OAuth2) . Mã thông báo truy cập được máy chủ ủy quyền cấp, quyết định thời gian hợp lệ.Nó được "sử dụng" tại một máy chủ tài nguyên, có thể hoàn toàn tách biệt với máy chủ ủy quyền, do đó không có cơ sở nào trong OAuth2 để kết nối việc sử dụng với thời gian tồn tại của mã thông báo. Theo lý thuyết thì có thể kết hợp một thứ gì đó với nhau để tạo ra tác phẩm này, nhưng nghe có vẻ như là một ý tưởng tồi.

Nếu tôi có thể ăn cắp mã thông báo, tôi cũng có thể ăn cắp mã thông báo làm mới. Vì vậy, tôi đoán tôi không thực sự nhìn thấy điểm trong việc có một mã thông báo làm mới ở nơi đầu tiên ..

Mã thông báo truy cập được sử dụng lặp đi lặp lại và gửi bởi máy khách đến máy chủ ủy quyền. Mã thông báo làm mới được giữ lại bởi máy khách và chỉ được gửi trở lại máy chủ ủy quyền. Một khách hàng cũng phải xác thực để sử dụng thành công mã thông báo làm mới, vì vậy id khách hàng và bí mật cũng sẽ phải bị xâm phạm.

Nó không thực sự rõ ràng từ câu hỏi của bạn tại sao bạn đang sử dụng OAuth2. Bạn có lẽ nên mở rộng câu hỏi của bạn để làm rõ điều này. Nếu chỉ có một máy khách và một máy chủ REST, tại sao không chỉ sử dụng một cái gì đó giống như BASIC auth qua HTTPS?

Ngoài ra, khách hàng có phải là ứng dụng dựa trên trình duyệt không? Nếu vậy, tài khoản tên người dùng/mật khẩu không thực sự phù hợp để sử dụng trong ứng dụng khách không tin cậy.