Today, I’m going to give you the introduction to the WordPress REST API’s authentication through application passwords that I wish somebody would have given me when I first started messing around with the REST API. It’s just something where the documentation feels a little thin, it feels a little nebulous to understand, but once you wrap your head around, it’s a pretty simple little tool that kind of speeds up your development workflow, especially if you’re doing anything using.
The WordPress rest API custom endpoints, custom integrations, that sort of thing. It’s just a super handy skill to have and it makes your life easier. And then when you’re doing things like debugging the rest API with postman, which is a pretty common free tool that people use to check API endpoints and stuff basically.
This application password system is a very fast way to people to do anything with any rest API endpoint. Not just like the public ones on your WordPress website.
I think one of the places where I struggled is in the documentation. There’s basically one kind of paragraph on it. And then there is a link, which I think is new, which is nice to this older blog post where there actually is a pretty good breakdown here. So if you’re a fan of reading, you can definitely go through the blog post.
It kind of breaks it down as well. But let’s just take a look at why we would even use an application password, what, what the point of it is.
Permissions and Authentication
So when you’re hitting the rest API, some of the endpoints that you hit are public. So I could go to any WordPress site and I could put in the rest API URL for their posts. And I could fetch like some of their posts. Like I think it’s like 10 at a time. I could fetch their posts via the rest API, kind of similar to an RSS feed.
And I could pull information that way, but it’s not going to have everything. It’s just going to have some of the information. And I can’t use that API to like send information back to the user. Back to their site and insert a post. Right? That’s, you know, you have to have permissions to do that. So the way that that works is in any rest, API endpoint, there’s what’s called a permission callback.
And that permission callback is almost always tied to a current user can function.
WordPress is basically thinking, you’re a user, you’re logged into the site, what permissions do you have? Are you an author, a contributor, an admin, that sort of thing. So when you’re logged into WordPress and you’re in the block editor, it’s, you know, all of the REST API endpoints are really running that.
Through the current logged in user. And it pretty works pretty seamlessly, but when you’re trying to use another tool like postman or something to debug the rest API, and maybe you’re working on a custom endpoint or something, you basically have to tell WordPress, Hey, I’m a user of the site too. And you do that through an application password, which it’ll then use to basically determine, Hey, what can this current user do?
Hitting Endpoints in Postman
So we’re looking at Postman . I’m hitting the REST API endpoint for a local site that I’m working on. And you can see that WP dash JSON slash WP slash V2 slash posts. That’s just the core WordPress rest API. And also there’s other endpoints that are for custom plugins or something like that.
But we’re just pulling in the posts API endpoint, but I have no authorization turned on right now. So it’s letting me pull in posts. It doesn’t let me pull in all of them, but what if I wanted to hit the endpoint for settings and pull like, you know, the site logo, the site name, you know, basically things that are saved as options, if I submit that.
Rest is forbidden. I’m not allowed to do that because I’m not a logged in user. I’m just somebody hitting the rest API endpoint. So let’s get an application password and pop it into Postman so I can actually hit that API endpoint.
Getting an Application Password
So I’m logged into my local environment and I just went to my edit profile screen for my user. And what I’m going to do is scroll down until I find the application passwords. It’s going to be this section right here, and I’m going to get to add a new application password. So I can just give it whatever the name is.
It’s really just a way to remember what it’s going to be. I could call it testing or something like that. I’m going to add it. It’s going to give me that password in plain text, and it’s really only going to do that one time. So once you’ve done it it’s not going to happen again. So you basically copy it
then. The way application passwords work is, you know, when you log into WordPress, you use your username and password. We’re going to do the same thing, but instead of using our normal password that we log into the front end of WordPress, we’re going to make a custom application password. That’s generated for us.
And then what that means is we can revoke that access at any time because it’s not tied to like our regular password. It’s a separate password just for this kind of you know, application instance of accessing the data. So I’m going to copy this password.
And then if I scroll down here, you can see One that I’ve made before when it was created, when it was last accessed the IP address, and then I can immediately revoke any access. And this is just tied to my user. So it’s, it’s, it’s whatever my user has access to in this WordPress site. In this case, I’m an admin, so that’s everything.
But even an author or a contributor level user could do the same process. And their username and password combo would just give them a lot less access to the rest API. So I created my password. I’m going to copy that.
Setting up Basic Auth in Postman
So I’m back in Postman and typically when you’re hitting an API, you’re not doing it through a nice UI like Postman, but when you’re doing a lot of like testing, debugging, that sort of thing, you are. So the nice thing about Postman is it gives us a UI to put in our basic auth credentials. If I were using, you know, if I were.
Getting to the place where I was actually writing code and stuff like that. Then I would use the basic auth approach to passing it as, as a header. But in this case Postman is going to do all that for us, which is kind of what we’re going to focus on today.
So I should be able to enter my username for the site and then my password, my application password, not just my regular password. So let’s do that real quick.
And then now when I submit the same Rest API request, I should have basically the full access that my user does, which is a full administrator access to WordPress. Yep. And there we go. So I can see I’m pulling in all of these option data right here. This is basically everything that’s automatically exposed to the settings API, but I could do things like post updates to it, test different things like that, test custom endpoints, that sort of thing, because now I’ve authenticated.
With a real administrative user. And so what’s nice about this is once you start setting up other situations, you’re going to use this to maybe connect with other WordPress sites or test your custom endpoints.
And it’s just a really handy way to just immediately, quickly get full access to testing the rest API, but keeping those user level permissions in place.
Hopefully this was a good introductory primer to application passwords. I’ll just end with the note that there’s so much more you can do with application passwords. There is this great little UI built into WordPress where you can actually request the passwords, kind of like when you authenticate with Google or something like that, you can actually ask somebody, send somebody a URL, give them a screen like this.
They can approve, and it’ll actually send you back those credentials, those sorts of things. So it’s a really cool way to get access to other sites and stuff. I won’t dig into how this works, but just know that there’s a lot of cool potential here and maybe in a future video, we’ll dig deeper into some of the cool workflows you can do with application passwords and other ideas relating to that.
So let me know if that’s something you’d be interested in, or if you have any other questions, throw them in the comments.