Mật khẩu, Token, Phiên, OAuth2: Ý Nghĩa Của Những Thuật Ngữ Này Trong Danh Sách

Danh sách mô tả những gì bạn sẽ nhận được bằng các từ lấy từ tài liệu dành cho nhà phát triển: token, session, OAuth2. Bất kỳ ai từng làm việc với API đều đã gặp cả ba thuật ngữ này, và đó chính là vấn đề, bởi vì trên một danh sách, mỗi thuật ngữ lại mang nghĩa hẹp và cụ thể hơn so với trong tài liệu gốc của chúng.

Hiểu sai điều này là sai lầm đắt giá nhất có thể xảy ra ở đây, vì sự không khớp về định dạng thường dẫn đến mất trắng thay vì mất một phần. Tài khoản có thể đúng y như mô tả nhưng vẫn không dùng được cho mục đích bạn mua nó.

Chỉ có mật khẩu

Bạn nhận được: một định danh và một mật khẩu. Không gì khác.

Đây là định dạng duy nhất không có nghĩa ẩn, và đáng chú ý là nó không bao gồm những gì. Không có yếu tố xác thực thứ hai, điều này có hai mặt: bạn có thể tự đặt ngay một yếu tố của riêng mình, nhưng bất kỳ ai khác giữ thông tin đăng nhập đó cũng làm được như vậy. Nếu người đăng ký ban đầu vẫn còn một đường khôi phục, mật khẩu là vị thế yếu nhất bạn có thể nắm giữ, vì đó là thứ mà quy trình khôi phục được thiết kế để đặt lại.

Ổn nếu chỉ thỉnh thoảng đăng nhập. Lựa chọn kém nếu bạn định giữ lâu dài.

Mật khẩu cộng thêm yếu tố xác thực thứ hai

Bạn nhận được: phần trên, cộng thêm thứ gì đó đáp ứng bước thứ hai. Và đây là nơi các danh sách gộp ba thứ khá khác nhau vào một từ duy nhất.

• Một bí mật dùng chung (hạt giống đằng sau ứng dụng xác thực) nghĩa là bạn có thể tự tạo mã vô thời hạn. Đây là phiên bản mạnh.
• Một danh sách mã dự phòng là một số lượng hữu hạn các lần dùng một lần. Khi dùng hết, bạn sẽ bị khóa ngoài trừ khi bạn đã thay yếu tố đó trước lúc đó.
• Mật khẩu đám mây, như Telegram sử dụng, là một chuỗi cố định thay vì thứ gì đó xoay vòng.

Câu hỏi cần đặt cho một danh sách là bạn đang nhận cái nào trong ba loại, vì "bao gồm 2FA" bao trùm cả ba và chúng không tương đương nhau. Một yếu tố thứ hai mà bạn không thể tạo lại là một bộ đếm ngược, không phải một tính năng bảo mật.

Token hoặc khóa API

Bạn nhận được: một chuỗi thông tin xác thực do nền tảng cấp, thường không kèm mật khẩu.

Đây là khoảng cách với nghĩa dành cho nhà phát triển. Trong tài liệu API, token thường là thứ bạn tự tạo và có thể tạo lại tùy ý. Trên danh sách, nó là thông tin xác thực đã tồn tại, bạn không tạo ra, và thường không thể gia hạn. Khi nó hết hạn hoặc bị thu hồi, nó biến mất, và không có mật khẩu nền tảng thì không có gì để dựa vào.

Sự khác biệt thứ hai cũng quan trọng không kém: token thường không thể dùng để đăng nhập qua giao diện web thông thường. Nếu kế hoạch của bạn là đăng nhập và thao tác, token không làm được điều đó, dù nó có hợp lệ đến đâu.

Tệp session

Bạn nhận được: dữ liệu đại diện cho một lần đăng nhập đã hoàn tất, chẳng hạn như thư mục TDATA của Telegram hoặc tệp .session, hoặc cookie trình duyệt cho một nền tảng web.

Đặc tính quan trọng nhất, và là điều gần như không ai nghĩ đến khi mua: session là một bản sao, và các bản sao không loại trừ lẫn nhau. Nhiều người có thể cùng giữ một session và tất cả đều đang đăng nhập. Việc nhận được một session không cho bạn biết liệu người khác có còn giữ nó hay không.

Cách duy nhất để biết là xem danh sách thiết bị được ủy quyền hoặc session hoạt động của nền tảng sau khi vào, và kết thúc những phiên bạn không nhận ra. Hãy coi đó là một phần của việc nhận hàng thay vì một bước bảo mật tùy chọn, và làm điều đó khi vẫn còn thời gian để khiếu nại.

OAuth2

Bạn nhận được: một refresh token, cùng với client id và secret mà nó được cấp.

Đây là định dạng mà sự thiếu sót phổ biến nhất và khó thấy nhất. Refresh token tồn tại để đổi lấy access token mới, nhưng việc đổi đòi hỏi thông tin client mà nó được cấp. Nhận refresh token mà không có chúng, bạn có một chuỗi hoạt động cho đến khi access token hiện tại hết hạn rồi ngừng vĩnh viễn.

Mọi thứ trông ổn khi giao hàng, và đó chính là vấn đề. Bài kiểm tra không phải là "nó có hoạt động bây giờ không" mà là "tôi có thể thực hiện refresh không", và đó là hai bài kiểm tra khác nhau. Hãy làm bài thứ hai.

Cách thị trường định giá định dạng, một cách không nhất quán

Đáng để biết vì nó ảnh hưởng đến nơi đáng để thương lượng:

• Trên Telegram, định dạng không được định giá gì cả. TDATA, session và JSON nằm cùng mức, nên không có lý do gì để chấp nhận loại sai.
• Trên một số kệ mailbox, truy cập giao thức là thuộc tính rẻ nhất được đo, gần như miễn phí, trong khi các thuộc tính xác minh có giá gần gấp đôi mức trung bình. Người mua tối ưu cho "công cụ của tôi có thể kết nối" đang tối ưu cho trục miễn phí.
• Trên một kệ mailbox, cùng thuộc tính giao thức có giá gần gấp đôi mức trung bình, nơi duy nhất xuất hiện sự đảo ngược đó. Thói quen của từng danh mục không chuyển qua được.

Vì vậy, khái quát hữu ích là không có khái quát nào cả. Hãy đọc giá của định dạng trên kệ mà bạn thực sự đang mua.

Những sai lầm nào bạn có thể gỡ lại được

Giao hàng diễn ra tức thì trên toàn danh mục và thời gian bảo hành trung bình là mười hai giờ, nên mọi kiểm tra dưới đây đều có thể thực hiện ngay và không cái nào làm được sau đó.

• Có thể gỡ lại: nhận định dạng mà công cụ của bạn không đọc được, nếu bạn phát hiện trong khung thời gian. Đó là sự không khớp rõ ràng, thực tế so với danh sách.
• Có thể gỡ lại nếu bạn chịu kiểm tra: một session mà người khác vẫn giữ, nhưng chỉ khi bạn kiểm tra danh sách thiết bị thay vì giả định.
• Thường không thể gỡ lại: một refresh token OAuth2 thiếu client credentials, nếu bạn chỉ kiểm tra rằng access token hiện tại hoạt động. Đến khi nó lỗi, khung thời gian đã đóng từ lâu.
• Không thể gỡ lại chút nào: mã dự phòng đã dùng hết. Không có phiên bản nào của tình huống này kết thúc tốt đẹp, đó là lý do việc xác định loại yếu tố thứ hai bạn được cấp nên đứng đầu danh sách.

Phiên bản dành riêng cho Telegram của bài viết này, đi sâu vào tệp TDATA và session, sẽ nói thêm về kệ đó. Danh sách kiểm tra trước khi mua bao gồm các kiểm tra xung quanh các định dạng này.