# Xác thực WordPress REST API: Application Password, cookie nonce hay JWT

> Đọc nội dung công khai qua REST API của WordPress không cần đăng nhập. Theo tài liệu chính thức, yêu cầu không có xác thực vẫn được xử lý, chỉ là với tư cách

URL: https://mona.software/xac-thuc-wordpress-rest-api/
Ngày đăng: 2026-10-13T10:29:00+07:00
Cập nhật: 2026-10-13T10:29:11+07:00
Tác giả: monamedia

Đọc nội dung công khai qua REST API của WordPress không cần đăng nhập. Theo tài liệu chính thức, yêu cầu không có xác thực vẫn được xử lý, chỉ là với tư cách người vô danh. Viết, sửa hoặc đọc dữ liệu riêng tư thì phải xác thực. WordPress có ba cách hay gặp: mật khẩu ứng dụng (Application Passwords) có sẵn trong lõi từ phiên bản 5.6, cookie kèm nonce dành cho JavaScript chạy trong chính site, và JWT qua plugin bên thứ ba. Cách nào đúng phụ thuộc vào việc app gọi API nằm ở đâu và nó đại diện cho ai.

Bài này đối chiếu với tài liệu chính thức của WordPress, tra ngày 13/10/2026. Phần nào thuộc lõi và phần nào là plugin được ghi tách bạch, để người đọc không nhầm một plugin với tính năng có sẵn.

## Application Passwords có từ phiên bản nào và dùng để làm gì

Application Passwords là tính năng có sẵn trong WordPress lõi từ phiên bản 5.6, phát hành tháng 12/2020. Tài liệu mô tả đây là mật khẩu gắn với một tài khoản WordPress cụ thể, dùng cho xác thực API như REST API, không dùng để đăng nhập trình duyệt. Mật khẩu được lưu dưới dạng băm trong WordPress và chỉ hiện một lần lúc tạo. Mỗi mật khẩu thu hồi riêng được.

![Trang Application Passwords của WordPress trên developer.wordpress.org nêu tính năng có từ phiên bản 5.6](https://mona.software/wp-content/uploads/2026/10/trang-application-passwords-wordpress-mona.webp)

Trang Application Passwords trên developer.wordpress.org, chụp ngày 13/10/2026. Trang ghi tính năng có từ WordPress 5.6, mật khẩu gắn với một tài khoản và chỉ hiện một lần khi tạo.

Mật khẩu ứng dụng không phải mật khẩu đăng nhập. Mật khẩu đăng nhập vào trang quản trị không cần đưa cho app, và mật khẩu ứng dụng lộ thì thu hồi riêng được mà không đổi mật khẩu chính. Đó là lý do tài liệu gợi ý dùng nó cho tích hợp, thay vì đưa mật khẩu chính cho bên thứ ba. Tích hợp bị cắt quyền truy cập trong khi người dùng vẫn đăng nhập bình thường.

Điều kiện HTTPS cũng cần nắm trước khi làm bất kỳ tích hợp nào. Theo tài liệu, mật khẩu ứng dụng mặc định chỉ khả dụng khi yêu cầu đi qua HTTPS. Basic Auth gửi tên người dùng và mật khẩu theo dạng có thể đọc được nếu đi trên mạng không mã hoá, do đó site chạy HTTP thuần thì bỏ qua cách này. [Bài hướng dẫn tích hợp năm 2020 của WordPress](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/) cũng cho biết có bộ lọc wp_is_application_passwords_available để đổi điều kiện này, nhưng cách làm đúng vẫn là bật HTTPS.

## Cách tạo mật khẩu ứng dụng và gọi thử bằng Basic auth

Các bước dưới đây theo đường dẫn trong [tài liệu chính thức về Application Passwords](https://developer.wordpress.org/advanced-administration/security/application-passwords/). Giao diện quản trị khác đi tuỳ phiên bản và plugin bảo mật, nhưng ý chính giữ nguyên: mở đúng tài khoản, tạo mật khẩu, rồi copy ngay.

1. Vào trang quản trị bằng tài khoản có quyền phù hợp, mở Người dùng rồi bấm Sửa ở tài khoản sẽ gắn với mật khẩu. Với tài khoản khác, tài liệu ghi đường dẫn Người dùng, Tất cả người dùng, Sửa.
2. Kéo xuống mục Application Passwords, nhập một tên dễ nhận ra cho tích hợp, ví dụ tên của app hoặc tên của script, rồi tạo mật khẩu mới.
3. Copy mật khẩu hiện ra ngay. WordPress không hiện lại mật khẩu này sau khi đóng hộp thoại. Muốn có mật khẩu mới thì phải tạo lại.
4. Gọi thử một endpoint chỉ đọc bằng cURL, theo đúng mẫu của tài liệu: curl –user “TÊN_NGƯỜI_DÙNG:xxxx xxxx xxxx xxxx xxxx xxxx” https://TÊN-MIỀN/wp-json/wp/v2/users?context=edit. Thay xxxx bằng mật khẩu ứng dụng thật ở máy của người chạy lệnh, không ghi vào tài liệu chung.
5. Kiểm phản hồi. Nếu trả về JSON có danh sách người dùng, xác thực đã đúng. Nếu lỗi, kiểm lại tên người dùng, xem có khoảng trắng thừa (tài liệu nói khoảng trắng trong mật khẩu là tuỳ chọn) và xác nhận site đang chạy HTTPS.

Với Basic auth, header Authorization gồm chữ Basic cộng với chuỗi base64 của “tên người dùng:mật khẩu ứng dụng”, theo [RFC 7617](https://www.rfc-editor.org/rfc/rfc7617). Lệnh cURL ở bước 4 tự làm việc mã hoá đó. Khi viết mã bằng ngôn ngữ khác, phải tự mã hoá đúng cách, và chỉ gọi qua HTTPS. Với tích hợp nhận sự kiện từ bên ngoài, như thông báo thanh toán, cách làm khác với gọi REST API, xem [webhook thanh toán là gì và cách tích hợp](https://mona.software/webhook-thanh-toan-la-gi-cach-tich-hop/). Mật khẩu ứng dụng không được nằm trong mã nguồn hay kho git. Hãy lưu trong biến môi trường hoặc kho bí mật của hạ tầng.

![Màn hình thống kê trong phần mềm MONA làm cho The IELTS Workshop](https://mona.software/wp-content/themes/monatheme/home-v2/assets/img/cs/ielts-thongke.webp)

Phần mềm cho việc này

Quy trình đang chạy mà phần mềm có sẵn không làm được?

MONA khảo sát nghiệp vụ trước dòng code đầu tiên.

[Viết phần mềm theo yêu cầu](https://mona.software/viet-phan-mem-theo-yeu-cau/)[Xem case study](https://mona.software/#case-study)

## Cookie và nonce chỉ dùng cho JavaScript trong chính site

Cookie là cơ chế xác thực tiêu chuẩn đi kèm WordPress. Nếu chưa rõ lõi WordPress gồm những gì, xem [WordPress là gì và khi nào đủ dùng](https://mona.software/wordpress-la-gi/). Khi người dùng đăng nhập trang quản trị, WordPress đặt cookie, do đó plugin và giao diện chỉ cần người dùng đã đăng nhập là đủ về mặt cookie. Để chống CSRF, REST API còn dùng nonce với action wp_rest. Nonce được gửi qua header X-WP-Nonce, hoặc qua tham số _wpnonce ở dữ liệu POST và chuỗi truy vấn của yêu cầu GET. Tài liệu cảnh báo rằng nếu không có nonce, WordPress đặt người dùng hiện tại về 0, tức yêu cầu thành không xác thực, dù người đó vẫn đang đăng nhập.

![Trang Authentication của REST API nói về nonce với action wp_rest và header X-WP-Nonce](https://mona.software/wp-content/uploads/2026/10/trang-authentication-rest-api-mona.webp)

Trang Authentication của REST API trên developer.wordpress.org, chụp ngày 13/10/2026. Trang nêu cookie là phương thức có sẵn, nonce dùng action wp_rest và được gửi qua header X-WP-Nonce.

Cơ chế này chỉ áp dụng khi REST API được dùng bên trong WordPress với người dùng đã đăng nhập. [Tài liệu xác thực của REST API](https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/) hướng dẫn tạo nonce ở phía máy chủ bằng wp_create_nonce(‘wp_rest’), rồi truyền sang JavaScript, ví dụ qua wp_localize_script. Cookie gắn với trình duyệt và với đúng site đó. Một app di động, một máy chủ khác hay một tích hợp chạy ngoài trình duyệt không có cookie ấy để gửi, cookie và nonce vì thế không hợp cho những trường hợp này. Với chúng, Application Passwords hoặc JWT là lựa chọn phù hợp hơn.

## JWT là plugin bên thứ ba và cần cảnh giác khi tự cấp token

JWT (JSON Web Token) không thuộc lõi WordPress. Cách chọn plugin nói chung có ở bài [Plugin WordPress là gì và cách chọn](https://mona.software/plugin-wordpress-la-gi/), còn phần này chỉ xét điểm liên quan tới xác thực. Tài liệu xác thực của WordPress có mục riêng cho các plugin xác thực bên thứ ba, và JWT nằm trong nhóm đó. Một plugin phổ biến trên kho wordpress.org là [JWT Authentication for WP REST API](https://wordpress.org/plugins/jwt-authentication-for-wp-rest-api/), do tác giả tmeister phát triển. Bản 1.5.0 có hơn 60.000 lượt cài theo trang plugin, tra ngày 13/10/2026. Theo trang plugin, plugin cần PHP tối thiểu 7.4, cần khai báo khoá bí mật JWT_AUTH_SECRET_KEY trong wp-config.php, và trang ghi rằng cần kích hoạt thêm plugin WP REST API.

JWT là cách dễ làm sai nhất trong ba cách. Trang plugin tự nói bảo mật của nó “rất mạnh khi được triển khai đúng”, và nhấn mạnh khoá bí mật phải đủ mạnh, không được để lộ. Bản miễn phí ký token bằng HS256, không hỗ trợ RS256 hay ES256, và không có làm mới hay thu hồi token. Thời hạn mặc định là 7 ngày, chỉnh bằng bộ lọc jwt_auth_expire. Vì không thu hồi được, một token lộ vẫn dùng được cho tới khi hết hạn. Muốn cắt ngay thì phải đổi khoá bí mật, và việc đó làm mọi token khác mất hiệu lực. Lưu token trong localStorage cũng để mã JavaScript trên trang đọc được token, và một lỗ hổng XSS đủ để lộ token. Đội vận hành gánh rủi ro đó.

![Hàng tủ máy chủ đen có dây mạng xanh trong phòng máy chủ](https://mona.software/wp-content/uploads/2026/10/tu-may-chu-mona.webp)

Tủ máy chủ xếp thành hàng trong phòng máy chủ. Ảnh của rawpixel.com, giấy phép CC0, nguồn rawpixel.com/image/5912401. Khoá bí mật và cấu hình HTTPS của JWT nằm trên hạ tầng này, vì vậy quyền truy cập máy chủ cũng là một phần của bảo mật.

Tài liệu chính thức chỉ nhắc OAuth 1.0a như một ví dụ plugin, không thuộc lõi. Bài này chưa đối chiếu được chi tiết OAuth 2.0 từ nguồn chính thức, và không đưa vào bảng so sánh. Plugin Basic Authentication cũng là một plugin riêng, khác với Application Passwords, và tài liệu cảnh báo chỉ dùng nó để phát triển và thử nghiệm. Khi AI Agent gọi phần mềm nội bộ, còn cần giới hạn thao tác và ghi nhật ký, xem thêm [MCP server là gì và cách cho AI Agent dùng phần mềm nội bộ an toàn](https://mona.software/mcp-server-la-gi/).

## Bảng so sánh ba cách xác thực

| Cách xác thực | Có từ đâu | Dùng khi nào | Phạm vi quyền | Rủi ro chính | Cần cài thêm gì |
| --- | --- | --- | --- | --- | --- |
| Application Passwords | Lõi WordPress từ 5.6 | Server, script hoặc app gọi REST API với một tài khoản cụ thể | Theo tài khoản gắn với mật khẩu | Mật khẩu lộ vẫn dùng được tới khi thu hồi; chỉ an toàn trên HTTPS | Không cần thêm plugin, chỉ cần HTTPS |
| Cookie và nonce (X-WP-Nonce) | Lõi WordPress | JavaScript chạy trong chính site khi người dùng đã đăng nhập | Theo người dùng đang đăng nhập và quyền của họ | Không dùng được cho app ngoài; yêu cầu thiếu nonce bị coi là không xác thực | Không cần |
| JWT | Plugin bên thứ ba | Client ngoài cần token, và đội kỹ thuật chấp nhận tự quản lý khoá và token | Theo nội dung token do plugin cấp | Bản miễn phí không thu hồi được token; khoá bí mật lộ là mất kiểm soát | Plugin JWT, khai báo khoá trong wp-config.php, theo trang plugin cần thêm plugin WP REST API |

Bảng trên tách các cách theo nơi chúng chạy. Cookie chỉ có ý nghĩa trong trình duyệt của chính site. Application Passwords và JWT dành cho những nơi không có cookie đó.

## Phạm vi quyền của mật khẩu ứng dụng theo tài khoản

Mật khẩu ứng dụng gắn với một tài khoản WordPress, phạm vi quyền bám theo tài khoản đó. Tài liệu chính thức không viết thẳng rằng mật khẩu ứng dụng có đúng quyền của tài khoản. Đây là suy luận từ việc nó được gắn với một người dùng cụ thể và từ cách REST API kiểm tra quyền của người dùng. Đội kỹ thuật cần kiểm lại bằng thử nghiệm trên site của mình.

Theo suy luận đó, một mật khẩu tạo từ tài khoản Editor không làm được những thao tác mà Editor không có, ví dụ thao tác quản trị cấu hình hay quản lý người dùng. Muốn tích hợp làm việc quản trị, phải gắn nó với tài khoản Administrator, và khi đó mọi lộ lọt đều nặng hơn. Cách gọn là tạo một tài khoản kỹ thuật riêng, chỉ có vai trò cần thiết cho tích hợp, thay vì dùng tài khoản quản trị chính.

Có plugin bên thứ ba như Mandate App Security cho phép giới hạn quyền theo từng mật khẩu ứng dụng. Tài liệu lõi không mô tả tính năng này. Nếu cần khoanh vùng từng tích hợp, đó là việc của plugin, không phải của WordPress lõi. Trước khi nghiệm thu một tích hợp, nên đối chiếu với [cách kiểm tra bảo mật trước nghiệm thu theo OWASP](https://mona.software/nghien-cuu/kiem-tra-bao-mat-truoc-nghiem-thu-owasp/).

## Thu hồi mật khẩu ứng dụng khi nghi bị lộ

Khi một tích hợp bị nghi lộ, thu hồi ngay mật khẩu đó trong màn hình Edit User. Tài liệu cho biết có thể thu hồi từng mật khẩu riêng, không cần đổi mật khẩu đăng nhập của tài khoản. Với máy chủ có WP-CLI, lệnh tương đương là wp user application-password delete, kèm ID người dùng và UUID của mật khẩu. Bảng mật khẩu ứng dụng còn có cột Last Used, theo bài hướng dẫn tích hợp của WordPress, độ chính xác trong vòng 24 giờ, dùng được để tìm mật khẩu ít dùng và thu hồi trước.

Website WordPress bị dò quét gần như liên tục, nên thu hồi nhanh có ý nghĩa thực tế, xem [website WordPress bị dò những gì mỗi ngày](https://mona.software/nghien-cuu/website-wordpress-bi-do-nhung-gi-moi-ngay/). Sau khi thu hồi, tạo mật khẩu mới cho tích hợp, cập nhật nơi lưu bí mật, rồi xem lại nhật ký truy cập để biết mật khẩu cũ đã được dùng cho việc gì trước khi bị thu hồi.

![Nhiều ổ khoá treo trên hàng rào lưới, dây buộc màu đỏ](https://mona.software/wp-content/uploads/2026/10/o-khoa-mat-khau-mona.webp)

Nhiều ổ khoá treo trên hàng rào lưới, mỗi ổ một khoá riêng, giống cách mỗi tích hợp có một mật khẩu riêng để thu hồi độc lập. Ảnh của Image Catalog, giấy phép CC0, nguồn flickr.com/photos/132795455@N08/17563633904.

## Hỏi đáp

### Mật khẩu ứng dụng có thay mật khẩu đăng nhập không?

Không. Mật khẩu ứng dụng là thông tin riêng cho API, được tạo từ trang hồ sơ người dùng và thu hồi riêng lẻ. Mật khẩu đăng nhập vẫn dùng cho trang quản trị như trước.

### Application Passwords có bắt buộc HTTPS không?

Theo tài liệu, mật khẩu ứng dụng mặc định chỉ khả dụng khi yêu cầu đi qua HTTPS, vì Basic Auth có thể bị nghe lén trên mạng không mã hoá. Đây là điều kiện thực tế cần đặt trước khi làm bất kỳ tích hợp nào.

### Có nên chọn JWT cho app di động không?

JWT dùng được, nhưng đội kỹ thuật phải chấp nhận tự quản lý khoá bí mật và phải xử lý việc token không thu hồi được trong bản miễn phí. Với tích hợp giữa các server, Application Passwords ít thành phần phải tự xây hơn. Đó là điểm cần chốt.

### Cookie và nonce có dùng cho app di động được không?

Không hợp lý. Cookie và nonce chỉ hoạt động khi REST API chạy trong WordPress với người dùng đã đăng nhập. App ngoài không có cookie của site, vì thế cần cách xác thực khác.

### Khi làm website headless WordPress, ai cần xác thực?

Phần đọc nội dung công khai thường không cần xác thực. Xác thực cần khi giao diện riêng ghi dữ liệu, tạo bài, hoặc đọc nội dung chưa công khai. Vì vậy cách xác thực thường được chốt từ đầu dự án, trước khi viết lớp kết nối. Xem thêm [Headless WordPress là gì và khác WordPress thường ở đâu](https://mona.software/nghien-cuu/headless-wordpress-la-gi-khac-gi-wordpress-thuong/) để hiểu vì sao lớp này tách khỏi giao diện.

Nếu website WordPress của doanh nghiệp đang làm nguồn nội dung cho một giao diện riêng, phần xác thực REST API quyết định ai được đọc và ai được ghi dữ liệu ở đâu. MONA Software nhận [dịch vụ lập trình website headless WordPress](https://mona.software/dich-vu-lap-trinh-website-headless-wordpress/). Để trao đổi cụ thể về cấu hình xác thực cho dự án, gọi hotline 1900 636 648.

## Đọc thêm

- [WordPress REST API là gì? Các endpoint cần biết và cách gọi thử](https://mona.software/wordpress-rest-api-la-gi/)
- [Đưa custom post type và trường tùy chỉnh ra REST API bằng show_in_rest](https://mona.software/custom-post-type-ra-rest-api-show-in-rest/)
- [WPGraphQL hay REST API cho WordPress: chọn theo việc cần làm](https://mona.software/wpgraphql-hay-rest-api-cho-wordpress/)

## Câu hỏi thường gặp

### Mật khẩu ứng dụng có thay mật khẩu đăng nhập không?

Không. Mật khẩu ứng dụng là thông tin riêng cho API, được tạo từ trang hồ sơ người dùng và thu hồi riêng lẻ. Mật khẩu đăng nhập vẫn dùng cho trang quản trị như trước.

### Application Passwords có bắt buộc HTTPS không?

Theo tài liệu, mật khẩu ứng dụng mặc định chỉ khả dụng khi yêu cầu đi qua HTTPS, vì Basic Auth có thể bị nghe lén trên mạng không mã hoá. Đây là điều kiện thực tế cần đặt trước khi làm bất kỳ tích hợp nào.

### Có nên chọn JWT cho app di động không?

JWT dùng được, nhưng đội kỹ thuật phải chấp nhận tự quản lý khoá bí mật và phải xử lý việc token không thu hồi được trong bản miễn phí. Với tích hợp giữa các server, Application Passwords ít thành phần phải tự xây hơn. Đó là điểm cần chốt.

### Cookie và nonce có dùng cho app di động được không?

Không hợp lý. Cookie và nonce chỉ hoạt động khi REST API chạy trong WordPress với người dùng đã đăng nhập. App ngoài không có cookie của site, vì thế cần cách xác thực khác.

### Khi làm website headless WordPress, ai cần xác thực?

Phần đọc nội dung công khai thường không cần xác thực. Xác thực cần khi giao diện riêng ghi dữ liệu, tạo bài, hoặc đọc nội dung chưa công khai. Vì vậy cách xác thực thường được chốt từ đầu dự án, trước khi viết lớp kết nối. Xem thêm Headless WordPress là gì và khác WordPress thường ở đâu để hiểu vì sao lớp này tách khỏi giao diện. Nếu website WordPress của doanh nghiệp đang làm nguồn nội dung cho một giao diện riêng, phần xác thực REST API quyết định ai được đọc và ai được ghi dữ liệu ở đâu. MONA Software nhận dịch vụ lập trình website headless WordPress. Để trao đổi cụ thể về cấu hình xác thực cho dự án, gọi hotline 1900 636 648.