Title: Application Passwords: Integration Guide
Author: George Stephanis
Published: November 5, 2020
Last modified: October 10, 2024
---
[ ](https://profiles.wordpress.org/georgestephanis/) [George Stephanis](https://profiles.wordpress.org/georgestephanis/)
8:29 pm _on_ November 5, 2020
Tags: [5.6 ( 85 )](https://make.wordpress.org/core/tag/5-6/),
[application-passwords ( 4 )](https://make.wordpress.org/core/tag/application-passwords/),
[authentication ( 4 )](https://make.wordpress.org/core/tag/authentication/), [core-passwords ( 2 )](https://make.wordpress.org/core/tag/core-passwords/),
[dev-notes ( 648 )](https://make.wordpress.org/core/tag/dev-notes/), [rest-api ( 111 )](https://make.wordpress.org/core/tag/rest-api/),
[two-factor ( 12 )](https://make.wordpress.org/core/tag/two-factor/)
# Application Passwords: Integration Guide
WordPress 5.6 will finally see the introduction of a new system for making authenticated
requests to various WordPress APIs — Application Passwords.
The existing cookie-based authentication system is not being removed, and any custom
authentication solutions provided by plugins should continue to operate normally.
For any sites using the [Application Passwords feature plugin](https://github.com/wordpress/application-passwords),
it is recommended to deactivate the pluginPlugin A plugin is a piece of software
containing a group of functions that can be added to a WordPress website. They can
extend functionality or add new features to your WordPress websites. WordPress plugins
are written in the PHP programming language and integrate seamlessly with WordPress.
These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. after upgrading to WordPress 5.6.
However, sites won’t experience any errors if the plugin remains active. The current
plan is to use the plugin for future prototyping.
## Application Password Format
Application Passwords are [**24**-characters long](https://github.com/WordPress/wordpress-develop/blob/87ff38532d8f4d9f48e67e3af171ea1a88798f6d/src/wp-includes/class-wp-application-passwords.php#L25-L32),
generated by `[wp_generate_password()](https://github.com/WordPress/wordpress-develop/blob/87ff38532d8f4d9f48e67e3af171ea1a88798f6d/src/wp-includes/class-wp-application-passwords.php#L49)`
without the use of special characters — so they consist exclusively of upper-case,
lower-case, and numeric characters. For the cryptographically curious, that comes
to [over **142 bits** of entropy](https://github.com/WordPress/application-passwords/pull/34/commits/71f5e9a66f9fa552e07bb11cf981ee1f648e3516).
When presented to the user for entering into an application, they are displayed
[**chunked** for ease of use](https://github.com/WordPress/wordpress-develop/blob/87ff38532d8f4d9f48e67e3af171ea1a88798f6d/src/wp-includes/class-wp-application-passwords.php#L305-L317),
like so:
```notranslate
abcd EFGH 1234 ijkl MNOP 6789
```
Application passwords can be used **with or without the spaces** — if included,
spaces will just be stripped out before the password is hashed and verified.
### Data Store
WordPress will be storing a user’s application passwords as an array in user metaMeta
Meta is a term that refers to the inside workings of a group. For us, this is the
team that works on internal WordPress sites like WordCamp Central and Make WordPress.,
similar to how interactive login sessions (via `WP_Session_Tokens`) are stored already.
[The `WP_Application_Passwords` class](https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/class-wp-application-passwords.php)
has all the methods for storing and retrieving records. Records include a number
of attributes about them — including assigned name for the application, a timestamp
for when it was created, and data on their last usage such as, date and IP address.
[Each application password is also assigned a uuid for reference](https://github.com/WordPress/wordpress-develop/blob/e4fadc6f4db4306374f5717fccef82df5c6ac4e8/src/wp-includes/class-wp-application-passwords.php#L53),
in case you’d like to build infrastructure for additional properties and store them
in an alternate location.
## Getting Credentials
### Generating Manually
From the Edit User page, you can generate new, and view or revoke existing application
passwords. [The form](https://github.com/WordPress/wordpress-develop/blob/530493396b324f5bed518a494e2843e7fdb020f1/src/wp-admin/user-edit.php#L723-L730)
and [the list table](https://github.com/WordPress/wordpress-develop/blob/530493396b324f5bed518a494e2843e7fdb020f1/src/wp-admin/includes/class-wp-application-passwords-list-table.php)
are both fully extensibleExtensible This is the ability to add additional functionality
to the code. Plugins extend the WordPress core software. to allow for overloading
to store additional data (more on this later, in “Authentication Scoping”).
[⌊The Application Passwords section of Edit User screen, after a new application
password has been created.⌉⌊The Application Passwords section of Edit User screen,
after a new application password has been created.⌉[
The Edit User screen, after a new application password has been created.
Once a given password has been used, it will keep track of where and when it has
been used – the “Last Used” column is accurate to within 24 hours (so that WordPress
isn’t writing to the database on every usage — only if it’s a new day). This can
be incredibly useful for identifying passwords that are no longer in use, so that
they can be safely revoked.
### Authorization Flow
To ensure that application password functionality is available, fire off a request
to the REST APIREST API The REST API is an acronym for the RESTful Application Program
Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is
how the front end of an application (think “phone app” or “website”) can communicate
with the data store (think “database” or “file system”) [https://developer.wordpress.org/rest-api/](https://developer.wordpress.org/rest-api/)
root URLURL A specific web address of a website or web page on the Internet, such
as a website’s URL www.wordpress.org, and look at [the `authentication` key in the response data](https://github.com/WordPress/wordpress-develop/blob/530493396b324f5bed518a494e2843e7fdb020f1/src/wp-includes/rest-api.php#L1099-L1119).
If this key is empty, then application passwords are not available (perhaps because
the request is not over `https://` or it has been intentionally disabled).
If, however, `response.authentication` is an object with a key of `application-passwords`
it will offer a URL to send a user to complete the authentication flow. (You could
just guess at the URL, but this gives us more of the relevant information in one
go, as well as confirming that application passwords are available and enabled.)
The `response.authentication['application-passwords'].endpoints.authorization` url
will likely look something like this:
`https://example.com/wp-admin/authorize-application.php`
Instead of just sending the user there to generate an application password, it would
then be up to the user to reliably re-enter it into your application. So instead,
some additional `GET` parameters are accepted along with the request:
* `app_name` (_required_) – The human readable identifier for your app. This will
be the name of the generated application password, so structure it like … “WordPress
Mobile App on iPhone 12” for uniqueness between multiple versions.
Whatever name
you suggest can be edited by the user if they choose before the application is
created. While you can choose to not pre-populate it for the user, it is required
to create a password, so they will then be forced to create their own, and could
select a non-intuitive option.
* `app_id` (_recommended_) – [a UUID formatted identifier](https://github.com/WordPress/wordpress-develop/blob/e3f28a9a11fd2c6eea7862a616738ace01d09d26/src/wp-includes/functions.php#L6990-L7038).
The `app_id` allows for identifying instances of your application, it has no
special meaning in and of itself. As a developer, you can use the `app_id` to
locate all Application Passwords created for your application.
In the event of
a data breach, your `app_id` could be distributed to void credentials generated
with it, or if a site wants to allow only a given `app_id` or set of `app_id`
s to register, this would enable that. However, it is strictly on the honor system—
there is nothing to stop applications from generating new uuids with every authorization.
* `success_url` (_recommended_) – The URL that you’d like the user to be sent to
if they approve the connection. Three `GET` variables will be appended when they
are passed back (`site_url`, `user_login`, and `password`); these credentials
can then be used for APIAPI An API or Application Programming Interface is a
software intermediary that allows programs to interact with each other and share
data in limited, clearly defined ways. calls.
If the `success_url` variable is
omitted, a password will be generated and displayed to the user instead, to manually
enter into their application.
* `reject_url` (_optional_) – If included, the user will get sent there if they
reject the connection. If omitted, the user will be sent to the `success_url`,
with `?success=false` appended to the end.
If the `success_url` is omitted, the
user just will be sent to their WordPress dashboard.
[⌊A screenshot of the new Authorize Application screen in the WP-Admin. A button
is displayed to approve the connection, and one to reject the connection.⌉⌊A screenshot
of the new Authorize Application screen in the WP-Admin. A button is displayed to
approve the connection, and one to reject the connection.⌉[
A screenshot of what the authorization flow will look like to a user.
As the parameters are all passed in via GET variables, if the user needs to log
in first, they will all be preserved through the redirect parameter, so the user
can then continue with authorization.
It is also worth noting that the `success_url` and `redirect_url` parameters will
generate an error if they use a `http://` rather than `https://` protocol — however
other application protocols **are** acceptable! So if you have a `myapp://` link
that opens your [Android](https://developer.android.com/training/app-links), [iOS / MacOS](https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content),
or [Windows](https://blogs.windows.com/windowsdeveloper/2016/10/14/web-to-app-linking-with-appurihandlers/)—
_those will work!_
[Here is an example of a simple javascript application (under 100 lines of code) that uses this to authenticate to a WordPress site](https://gist.github.com/georgestephanis/44d16dfdd17bd18b9c45d1d5e6d7ec7b).
Though not the tidiest code, it was created in under two hours one evening, but
it goes through the proper flows and can make authenticated requests.
### Programmatically through the REST API
If you have previously been using a different system to access the REST API and
would prefer to switch over to using application passwords, it’s easy! [You can generate yourself a new application password via a `POST` request to the new `/wp/v2/users/me/application-passwords` endpoint.](https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/rest-api/endpoints/class-wp-rest-application-passwords-controller.php)
Once you’ve got the new application password in the response data, you can delete
any old credentials and just use the coreCore Core is the set of software required
to run WordPress. The Core Development Team builds WordPress. implementation instead—
but please consider using something like [libsodium](https://github.com/jedisct1/libsodium)(
which [has a library bundled with WordPress already](https://github.com/WordPress/wordpress-develop/tree/master/src/wp-includes/sodium_compat)—
[here’s an implementation example](https://github.com/WordPress/two-factor/pull/389))
or [Vault](https://www.vaultproject.io/) to store the credentials encrypted, rather
than in plaintext.
## Using Credentials
### REST API
The credentials can be passed along to REST API requests served over `https://`
using [Basic Auth](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme)/
[RFC 7617](https://tools.ietf.org/html/rfc7617), which is nearly ubiquitous in its
availability — [here’s the documentation for how to use it with cURL](https://ec.haxx.se/http/auth.html).
For a simple command-line script example, just swap out `USERNAME`, `PASSWORD`,
and `HOSTNAME` in this with their respective values:
```notranslate
curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit
```
### XML-RPC API
To use a generated application password with the legacy XML-RPC API, you can just
use it directly in lieu of the account’s real password.
For a simple command-line script example, again just swap out `USERNAME`, `PASSWORD`,
and `HOSTNAME` in this with their respective values:
```notranslate
curl -H 'Content-Type: text/xml' -d 'wp.getUsers1USERNAMEPASSWORD' https://HOSTNAME/xmlrpc.php
```
### Future 🔮 APIs
The application passwords authentication scheme can also be applied to future APIs
for WordPress as they become available. For example, if GraphQL or other systems
are enabled in WordPress, application passwords will provide them with a solid,
established authentication infrastructure to build off of out of the box.
As an example of this, [with a trivial code addition identifying whether the current load is an api request](https://github.com/wp-graphql/wp-graphql/pull/1529),
[WPGraphQL](https://www.wpgraphql.com/) will now be able to accept authenticated
requests without the need of an ancillary plugin, using just the application passwords
functionality that has merged into core.
### Using an Application Password on `wp-login.php`
You can’t. 😅 The _point_ of application passwords are that they are to be used
programmatically for applications, and not by humans for interactive sessions.
## Feature Availability
By default, Application Passwords is available to all users on sites served over
SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet.
Used for authenticated and private actions./HTTPSHTTPS HTTPS is an acronym for Hyper
Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol
over which data is sent between your browser and the website that you are connected
to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications
between your browser and the website are encrypted. This is especially helpful for
protecting sensitive data like banking information.. This can be customized using
the `wp_is_application_passwords_available` and `wp_is_application_passwords_available_for_user`
filters.
For example, to completely disable Application Passwords add the following code
snippet to your site.
```notranslate
add_filter( 'wp_is_application_passwords_available', '__return_false' );
```
Without SSL, it is possible for the Application Password to be seen by an attacker
on your networknetwork (versus site, blog) or the network between your site and
the authorized application. If you are ok with this risk, you can force availability
with the following code snippet.
```notranslate
add_filter( 'wp_is_application_passwords_available', '__return_true' );
```
If desired, it is possible to restrict what users on your site can use the Application
Passwords feature. For example, to restrict usage to administrator users, use the
following code snippet.
```notranslate
function my_prefix_customize_app_password_availability(
$available,
$user
) {
if ( ! user_can( $user, 'manage_options' ) ) {
$available = false;
}
return $available;
}
add_filter(
'wp_is_application_passwords_available_for_user',
'my_prefix_customize_app_password_availability',
10,
2
);
```
## Future Development
### Authentication Scoping
In future versions, the expectation is to include the ability to scope a given application
password to limit its access. The intention is to work on building this in plugin-
land until it’s ready for a core proposal.
What might password scoping look like? Here’s some methods being considered:
* In a multisitemultisite Used to describe a WordPress installation with a network
of multiple blogs, grouped by sites. This installation type has shared users
tables, and creates separate database tables for each blog (wp_posts becomes
wp_0_posts). See also **network**, **blog**, **site** environment, either restrict
the credentials to a subset of the user’s blogs, or restrict it to only operate
in a normal “blogblog (versus network, site) adminadmin (and super admin)” context,
and not a “network admin” context.
* Restrict functionality to only manage content — posts, pages, comments, custom
post types — and disallow infrastructure management functionality like managing
plugins, themes, and users.
* Restrict the role that credentials can allow an application to operate as. For
example, an Editor may restrict a set of credentials to only operate as though
they had Author or Contributor permissions.
However this is done, implementing additional functionality to enforce the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)
on an application-by-application basis is a worthwhile expansion on the included
functionality.
### Fine-grained Capabilitiescapability A **capability** is permission to perform one or more types of task. Checking if a user has a capability is performed by the `current_user_can` function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability).
Right now, a user’s application passwords can be managed by any user who has permission
to `edit_user` them. The ability to customize this behavior using a new set of more
fine-grained capabilities is currently [planned for 5.7](https://core.trac.wordpress.org/ticket/51703).
### Eventually Two-Factor Authentication?
Another useful bit of application passwords is that it will removes an obstacle
for the inclusion of multi-factor authentication on interactive logins.
Previously, if you enabled an interactive step — whether captcha or second factor
validation — on login pages, you would be in a bind with other non-interactive authentications,
for example the legacy XML-RPC system. After all, if a bad actor can just brute
force or use social engineering to discern the user’s password, it would be trivially
usable via XML-RPC, where there is no ability to include an interactive prompt,
and that functionality would need to be disabled entirely.
With that use case now being provided for via application passwords, there is additional
flexibility for the normal browser-based `wp-login.php` system to evolve.
### Further Resources
* Core Ticketticket Created for both bug reports and feature development on the
bug tracker.: [#42790](https://core.trac.wordpress.org/ticket/42790)
* [Merge Proposal](https://make.wordpress.org/core/2020/09/23/proposal-rest-api-authentication-application-passwords/)
* [Example Client](https://gist.github.com/georgestephanis/44d16dfdd17bd18b9c45d1d5e6d7ec7b)
* [Feature Plugin](https://github.com/wordpress/application-passwords). Further
development of App Passwords will be prototyped in this repo.
For bugbug A bug is an error or unexpected result. Performance improvements, code
optimization, and are considered enhancements, not defects. After feature freeze,
only bugs are dealt with, with regressions (adverse changes from the previous version)
being the highest priority. reports or enhancements, open a [Trac ticket](https://core.trac.wordpress.org/newticket?component=Login+and+Registration&focuses=rest-api)
in the new _App Passwords_ component with the _rest-api_ focus.
_Props [@timothyblynjacobs](https://profiles.wordpress.org/timothyblynjacobs/),
[@m\_butcher](https://profiles.wordpress.org/m_butcher/), [@desrosj](https://profiles.wordpress.org/desrosj/),
[@jeffmatson](https://profiles.wordpress.org/jeffmatson/), for helping to write,
review, and proofread._
[#5-6](https://make.wordpress.org/core/tag/5-6/), [#application-passwords](https://make.wordpress.org/core/tag/application-passwords/),
[#authentication](https://make.wordpress.org/core/tag/authentication/), [#core-passwords](https://make.wordpress.org/core/tag/core-passwords/),
[#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#rest-api](https://make.wordpress.org/core/tag/rest-api/),
[#two-factor](https://make.wordpress.org/core/tag/two-factor/)
### Share this:
* [ Threads ](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/?share=threads)
* [ Mastodon ](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/?share=mastodon)
* [ Bluesky ](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/?share=bluesky)
* [ X ](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/?share=x)
* [ Facebook ](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/?share=facebook)
* [ LinkedIn ](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/?share=linkedin)
1. 
2. [Clayton Collie](https://profiles.wordpress.org/claytoncollie/) 10:15 pm _on_
November 5, 2020
3. Thinking about Personal Access Tokens on GitHubGitHub GitHub is a website that
offers online implementation of git repositories that can easily be shared, copied
and modified by other developers. Public repositories are free to host, private
repositories require a paid subscription. GitHub introduced the concept of the‘
pull request’ where code changes done in branches by contributors can be reviewed
and discussed before being merged by the repository owner. [https://github.com/](https://github.com/);
when you create a token, the string is not chunked and also has a copy button.
They are small features but make a big difference. Could either of those make
the workflow smoother?
4. * 
* [George Stephanis](https://profiles.wordpress.org/georgestephanis/) 3:04
pm _on_ November 6, 2020
* We’d considered adding a “copy” button but saw it as an optional future enhancementenhancement
Enhancements are simple improvements to WordPress, such as the addition of
a hook, a new feature, or an improvement to an existing feature.. If you’re
interested in adding it, we’d love a pull request or ticketticket Created for
both bug reports and feature development on the bug tracker. to add it in!
🙂
5. 
6. [Cameron Jones](https://profiles.wordpress.org/cameronjonesweb/) 3:00 pm _on_
November 6, 2020
7. So if it’s chunked simply for ease of use, that should mean that it wouldn’t matter
if it is sent in a request as chunked or not, right?
8. * 
* [George Stephanis](https://profiles.wordpress.org/georgestephanis/) 3:03
pm _on_ November 6, 2020
* Yup! As noted,
* > Application passwords can be used with or without the spaces — if included,
> spaces will just be stripped out before the password is hashed and verified.
* The application passwords passed back through the authorization flow do not
include spaces. They are strictly there to make it easier for someone staring
at a long string to keep their place if manually entering it.
* They can be used chunked, without spaces, or — heck — if you wanted to, you
could probably add a space after every character. The regex will string any
non-alpha-numeric characters out before comparing it to application password
hashes on file.
9. 
10. [Sander van Dragt](https://profiles.wordpress.org/pacifika/) 9:33 am _on_ November
19, 2020
11. Must the application password acquisition flow always contain a browser based
wp-login before the APW is created? When a mobile app is first party, for the
user having to approve it is an unnecessary step. I guess this could be worked
around by auto-approving a certain app_id?
12. When logging in via a mobile app there is the desire to not have to login to the
site via the browser first, can a login be validated programmatically without
exposing the website to brute force attacks?
13. * 
* [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/) 7:08
pm _on_ November 20, 2020
* In this scenario, how would the mobile app be authenticating? The user needs
to login to provide an application password. The approval step is what generates
the Application Password that the Application can then use.
* It sounds like what you are asking for is akin to an OAuth 2 password grant.
App Passwords does not support this and there are no plans to.
14. 
15. [Chris](https://profiles.wordpress.org/camthor/) 4:57 pm _on_ November 24, 2020
16. So, if the request uses the correct username and application password, is then
the current user set to that corresponding user so that we can use `current_user_can()`
in the permission_callback of `register_rest_route()`?
17. * 
* [George Stephanis](https://profiles.wordpress.org/georgestephanis/) 5:39
pm _on_ November 24, 2020
* yup! It’s set for that request, but not persistent for subsequent requests.
18. 
19. [Chris](https://profiles.wordpress.org/camthor/) 10:15 am _on_ November 25,
2020
20. Maybe I’m still missing something. Directly in the callback for ‘rest_api_init’`
get_current_user_id()` works fine and I get the user ID. In the callback for ‘
permission_callback’, however, `get_current_user_id()` always returns 0. (Using
WP 5.6-RC1 on localhost with filterFilter Filters are one of the two types of
Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks).
They provide a way for functions to modify data of other functions. They are the
counterpart to Actions. Unlike Actions, filters are meant to work in an isolated
manner, and should never have side effects such as affecting global variables
and output. `wp_is_application_passwords_available` returning true.)
21. * 
* [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/) 3:28
pm _on_ November 25, 2020
* Can you share more about how you are testing? For example a minimal REST APIREST
API The REST API is an acronym for the RESTful Application Program Interface(
API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the
front end of an application (think “phone app” or “website”) can communicate
with the data store (think “database” or “file system”)
[https://developer.wordpress.org/rest-api/](https://developer.wordpress.org/rest-api/)
route registration, and the exact HTTPHTTP HTTP is an acronym for Hyper Text
Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web
and this protocol defines how messages are formatted and transmitted, and what
actions Web servers and browsers should take in response to various commands.
call you are making?
- 
- [Chris](https://profiles.wordpress.org/camthor/) 5:07 pm _on_ November
25, 2020
- Hooked into rest_api_init I register the route:
- ```notranslate
register_rest_route( 'my-plugin/v1', '/groups/(?P\d+)', array(
array(
'methods' => WP_REST_Server::EDITABLE,
'callback' => array( 'My_REST_API', 'edit_group' ),
'args' => array(
'id' => array(
'validate_callback' => function ( $param, $request, $key ) {
return is_numeric( $param );
},
),
),
'permission_callback' => array('My_REST_API', 'current_user_can_edit_groups'),
),
) );
```
- In the permission callback current_user_can_edit_groups() the current user
is not available, resulting in ‘rest_forbidden’.
- posted data (host and filename anonymized)
- ```notranslate
{
"POST": {
"scheme": "http",
"host": "testing",
"filename": "/wp-json/my-plugin/v1/groups/11/",
"remote": {
"Address": "[::1]:80"
}
}
}
```
- request headers:
- ```notranslate
POST /wp-json/my-plugin/v1/groups/11/ HTTP/1.1
Host: testing
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:83.0) Gecko/20100101 Firefox/83.0
Accept: */*
Accept-Language: en-US,en;q=0.8,de-DE;q=0.6,cs;q=0.4,ja;q=0.2
Accept-Encoding: gzip, deflate
authorization: Basic dGctYWRtaW46OWF etc. =
content-type: application/x-www-form-urlencoded
Origin: moz-extension://b093dd6e-a59a-2a4d-b57a-a6cc50337ae0
DNT: 1
Connection: keep-alive
Cookie: wp-settings-1=mfold%3Do%26libraryContent%3Dbrowse; wp-settings-time-1=1604312731; wp-wpml_current_language=en; wp-wpml_current_admin_language_d41d8cd98f00b204e9800998ecf8427e=en; wordpress_test_cookie=WP+Cookie+check; tk_ai=woo%3AMdtrBaUVPNTJkH4eNTOPIEcu; wordpress_logged_in_8746f36c5 etc.=some-username%7C16 etc.
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0
```
- As mentioned before, not using HTTPSHTTPS HTTPS is an acronym for Hyper
Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the
protocol over which data is sent between your browser and the website that
you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It
means all communications between your browser and the website are encrypted.
This is especially helpful for protecting sensitive data like banking information.
and therefore application passwords are enabled via the filterFilter Filters
are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks).
They provide a way for functions to modify data of other functions. They
are the counterpart to Actions. Unlike Actions, filters are meant to work
in an isolated manner, and should never have side effects such as affecting
global variables and output..
- thanks!
* 
* [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/)
9:29 pm _on_ December 5, 2020
* Sorry for the delay in responding to this [@camthor](https://profiles.wordpress.org/camthor/).
Looking at the headers you’ve sent, it appears that you are sending a
WordPress session cookies. Could you try omitting those? They shouldn’t
be sent when authenticating with App Passwords.
- 
- [Chris](https://profiles.wordpress.org/camthor/) 10:52 am _on_ December
7, 2020
- Thanks for following up! It works indeed with a clean session.
- The session cookie was from a session with the _same_ user who is
logged in using that browser, so I thought it wouldn’t make a difference.
* 
* [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/)
4:31 pm _on_ December 7, 2020
* I’ll make sure to note this in the docs. The issue I believe is
that cookie auth happens first in `determine_current_user` so application
passwords doesn’t try to authenticate. Then the REST APIREST API
The REST API is an acronym for the RESTful Application Program
Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE
data. It is how the front end of an application (think “phone app”
or “website”) can communicate with the data store (think “database”
or “file system”)
[https://developer.wordpress.org/rest-api/](https://developer.wordpress.org/rest-api/)
will log the user back out in `rest_cookie_check_errors` because
you aren’t passing a nonce.
22. 
23. Anonymous User 11:29 pm _on_ December 8, 2020
24. I think there could be something improved in the UIUI User interface that users
know from where the request come and where it leads to.
25. See [https://github.com/WP-API/authentication/issues/13#issuecomment-741210085](https://github.com/WP-API/authentication/issues/13#issuecomment-741210085)
26. I do not know if this is already the case. But it is better to show more than
just the application name. Compare that to OAuth flows in GitHubGitHub GitHub
is a website that offers online implementation of git repositories that can easily
be shared, copied and modified by other developers. Public repositories are free
to host, private repositories require a paid subscription. GitHub introduced the
concept of the ‘pull request’ where code changes done in branches by contributors
can be reviewed and discussed before being merged by the repository owner. [https://github.com/](https://github.com/)
and other platforms where you can connect applications in a similar way and you
get much more context and information when you connect them.
27. See also:
[https://github.com/WP-API/authentication/issues/13#issuecomment-741210085](https://github.com/WP-API/authentication/issues/13#issuecomment-741210085)
[https://github.com/WP-API/authentication/issues/13#issuecomment-741225441](https://github.com/WP-API/authentication/issues/13#issuecomment-741225441)
28. * 
* [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/) 5:01
pm _on_ December 11, 2020
* Hi [@danielrufde](https://profiles.wordpress.org/danielrufde/) the URLURL A
specific web address of a website or web page on the Internet, such as a website’s
URL www.wordpress.org is shown on the Authorize Application screen after the
Approve button, see the screenshot in the post under “Authorization Flow”.
The user isn’t guaranteed to hit `wp-login.php` so we shouldn’t be relying
on it for showing additional information.
29. 
30. [dingdang](https://profiles.wordpress.org/dingdang/) 6:47 pm _on_ December 9,
2020
31. Have you had a discussion there before implementing this into the coreCore Core
is the set of software required to run WordPress. The Core Development Team builds
WordPress. for possible negative security side effects?
32. Problem 1. The [https://example.com/wp-admin/authorize-application.php](https://example.com/wp-admin/authorize-application.php)
will be greatly exploited in fishing emails (“click here to authorize the …” with
some nice wording many people will do)
33. Problem 2. Even for legitimate authorizations like above, you are redirecting
with a GET request (i.e. plain URLURL A specific web address of a website or web
page on the Internet, such as a website’s URL www.wordpress.org with the plain
password) into the browser, so this URL will be stored in the history list of
the browser. Guess what will be the next thing that all the new trojan horses
will check for (the url has the site address, login name and a password for the
app). This is highly unsecure!
34. * 
* [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/) 5:07
pm _on_ December 11, 2020
* Hi [@dingdang](https://profiles.wordpress.org/dingdang/), yes these were both
discussed multiple times. You can view the merge proposal here for some of
the recent discussion: [https://make.wordpress.org/core/2020/09/23/proposal-rest-api-authentication-application-passwords/](https://make.wordpress.org/core/2020/09/23/proposal-rest-api-authentication-application-passwords/)
* 1. That is why we show the URLURL A specific web address of a website or web
page on the Internet, such as a website’s URL www.wordpress.org of the site
you are being redirected to. I don’t believe this is simpler to phish than
the standard WordPress Login page.
* 2. If your computer is infected with malware, they can monitor your keystrokes,
use your existing logged in session, request a password reset and follow in
thru your mail client. For all intents and purposes, it is already game over
at that point.
35. 
36. [dingdang](https://profiles.wordpress.org/dingdang/) 10:23 pm _on_ December
11, 2020
37. Thanks, but let me not agree.
38. 1. Creating a way to generate adminadmin (and super admin) access to the system
with a one click (when the user is already logged in) is not a good idea, it is
insecure, and for sure it will be exploited. You don’t assume that all the site
owners are tech savvy, do you? Have in mind that hackers don’t need a 100% success
at all. Sending an email to 1 million sites’ owners and just 0.1% of them to fail(
and get compromised) this makes 1000 hackedhacked sites.
39. 2. This is not true. First – not all malware are trojans catching the keyboard.
An exploit to access the local data would do it, too. And the most important a
trojan caught NOW would get access to all the passwords in the PAST (which is
not like getting all future passwords by watching the keyboard, someone might
not make new at all). It is common sense that sending plain passwords in a GET
URLURL A specific web address of a website or web page on the Internet, such as
a website’s URL www.wordpress.org request is a big security fail and I didn’t
expect such a thing could get into WP’s coreCore Core is the set of software required
to run WordPress. The Core Development Team builds WordPress.…
40. 
41. [Ahmad Awais](https://profiles.wordpress.org/mrahmadawais/) 1:17 pm _on_ December
12, 2020
42. Hi Georg,
43. Thanks for sharing the summary. Can you tell what happens to people who have the
pluginPlugin A plugin is a piece of software containing a group of functions that
can be added to a WordPress website. They can extend functionality or add new
features to your WordPress websites. WordPress plugins are written in the PHP
programming language and integrate seamlessly with WordPress. These can be free
in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. installed? I had that for three
years and each user had a couple of App Passwords generated. Now in 5.6, that
plugin is still active but I don’t see the app users’ credentials (which are still
working btw). Care to share the best way to migrate?
44. * 
* [Ahmad Awais](https://profiles.wordpress.org/mrahmadawais/) 1:18 pm _on_
December 12, 2020
* Forgot to tagtag A directory in Subversion. WordPress uses tags to store a
single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags
in version control systems. (Not to be confused with post tags.) you [@georgestephanis](https://profiles.wordpress.org/georgestephanis/)(
context: look for the best way to migrate to the native app passwords).
* 
* [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/) 7:20
pm _on_ December 12, 2020
* [@mrahmadawais](https://profiles.wordpress.org/mrahmadawais/) It depends on
how you are using App Passwords. If you are just using the UIUI User interface
to create passwords and then authenticate by passing the username and app password
as basic auth credentials, then you can simply deactivate the existing App
Passwords pluginPlugin A plugin is a piece of software containing a group of
functions that can be added to a WordPress website. They can extend functionality
or add new features to your WordPress websites. WordPress plugins are written
in the PHP programming language and integrate seamlessly with WordPress. These
can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party..
* If you are calling APIAPI An API or Application Programming Interface is a
software intermediary that allows programs to interact with each other and
share data in limited, clearly defined ways. functions in the `Application_Passwords`
class directly, then you’ll need to adjust your usage to use the new `WP_Application_Passwords`
class.
* Similarly, if you are using the App Passwords REST APIREST API The REST API
is an acronym for the RESTful Application Program Interface (API) that uses
HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of
an application (think “phone app” or “website”) can communicate with the data
store (think “database” or “file system”)
[https://developer.wordpress.org/rest-api/](https://developer.wordpress.org/rest-api/)
endpoints directly, you’ll need to migrate to use the new endpoints in `wp/
v2/application-passwords`.
* Lastly, if you were using the interactive authentication flow, you’ll need
to update your client application to follow the steps outlined in this post.
45. 
46. [Tim Nolte](https://profiles.wordpress.org/tnolte/) 4:15 am _on_ February 9,
2021
47. So I know that this is a tad bit of an old thread but I’m trying to trace down
how it is that this feature is being mentioned here to be introduced in WordPress
CoreCore Core is the set of software required to run WordPress. The Core Development
Team builds WordPress. 5.6 and I’ve had Application Passwords available since
September 2020, and I’m currently running WP 5.5.3. I also don’t have the feature
pluginFeature Plugin A plugin that was created with the intention of eventually
being proposed for inclusion in WordPress Core. See [Features as Plugins](https://make.wordpress.org/core/handbook/about/release-cycle/features-as-plugins/)
installed. Has this functionality been implemented ahead of time by some other
pluginPlugin A plugin is a piece of software containing a group of functions that
can be added to a WordPress website. They can extend functionality or add new
features to your WordPress websites. WordPress plugins are written in the PHP
programming language and integrate seamlessly with WordPress. These can be free
in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. like JetPack or WPGraphql? If
it is being provided by one of those I sure hope they are coordinating a release
with a check for this code being provided in WordPress Core.
Comments are closed.
# Post navigation
[← Dev Chat Summary: November 04 2020](https://make.wordpress.org/core/2020/11/05/dev-chat-summary-november-04-2020/)
[CSS Chat Agenda: 5 November 2020 →](https://make.wordpress.org/core/2020/11/05/css-chat-agenda-5-november-2020/)