Anders Stensaas

Bump!

Sweet. Then I really don´t understand what I need `wo_set_access_token´to. The only thing I can think about is to set some variables saying it´s Client Credentials or User Credentials.

Any specific object where I can access this information (the user id specifically)?

Thanks, Justin.

I don’t really see any obvious actions to apply any filters to, but I think it’s correct to apply an action to either:

– wo_set_access_token
– wo_endpoint_user_authenticated

Do you agree?

I am not really an expert on OAuth2.0 – it would be really nice with a tutorial. Of course, I don’t expect you to solve this problem for us, rather with us. However, we have a license (if that makes things different?). Would it be better if we made a support ticket on this?

Do you suggest extending the WP OAuth Server in a separate plugin? I don’t really know how to do this properly, and I really don’t want to edit the source files of this plugin.

It would be nice if you had something that would help me with this problem.

Thank you for the detailed answers so far, Justin.
However, I see now that I’ve not described my problem well enough. I will start from the beginning.

We have a WordPress site running 4.5. All the users who are authenticating through the webpage are registered in the WordPress database. After authenticating, these users are accessing private information through an integration to a CRM system. Of course, all of these users doesn’t have editor/admin rights in WordPress.

Our customer now wants an native app for their users.
Some requirements:
– We need to provide a REST API for the native app, because not all native apps can communicate through SOAP with the CRM system.
– All the users needs to authenticate in the native app, before they can do anything in it (access their private information etc.).

We are solving the authentication using this plugin (WP OAuth Server, v3.1.97, we bought the license right before v3.2 was announced.). The native app vendor wanted to use OAuth 2.0 with User Credentials for authenticating the native app users. Currently, we are using this method for authenticating users (by passing client_id, client_secret, grant_type=password, username and password). It seems like this works pretty good. Is there any problems with this?

The REST API is solved by extending the WP REST API v2 plugin, by creating a separate plugin.

Also, there exists an app backend which will synchronize all the users from the CRM system. This REST API method shouldn’t be able for regular users to access (it’s a pretty heavy and long running call). Only the app backend should be able to access this. How would one distinguish the regular users’s authentication and the app backend‘s authentication? Is this where we should use Client Credentials for the app backend?

These questions are out of scope for this plugin. I see that now. We should maybe PM instead.

The original question I asked is solved.

Actually, this is an excellent answer.

I played alot with this, and it seems like it’s not possible to use regular authentication and then call the REST API. It needs to be either Nonce og OAuth authentication. I don’t really need to check if the user is authenticated through the WP OAuth Server or not, since the REST API only supports Nonce and OAuth.

For the record, I’m running a native app.

The users who are authenticating through the REST API are not actually WordPress editors or admins. They are regular users, which do not have access to WordPress at all. It would not make sense to check their ‘roles’ by using current_user_can. We are talking about ~20.000 users, so setting these ‘roles’ on every user is not an option.

Do you understand what I’m saying?

It seems like I pressed some keys on my keyboard and a comma had changed place with a parenthesis (uh-oh!) in my theme-init.php. Changing this back fixed my problem!