Zf-oauth2: I've got access_token. What's next?

Questions API Tools
1

Earlier, I’ve thought that zf-oauth2 will do everything for me. I’ve thought there is some magic in this module which I don’t see. That is why I was stuck for a long time with apigility and oauth2.

I have login page for admin panel. Admin fills username and password fields. Request is sending to the server with ajax. If success I am getting from response client_id and client_secret for admin panel and send next ajax request to /oauth url with this post data:

var postData = {
                        	grant_type: 'password',
                        	username: response.data.username,
                        	password: self.password,
                        	client_id: response.data.client_id,
                        	client_secret: response.data.client_secret
                        };

In response I get this:

{
	"access_token":"dabae...c55e917cb61...9061a88...cd0...8e",
	"expires_in":3600,
	"token_type":"Bearer",
	"scope":null,
	"refresh_token":"6b17....04687d5...c5b98c...8230...8c7a72"
}
  1. Where to store access_token?

I need to make request calls to the rest urls like ‘/admin/api/user/1234’ or ‘/admin/api/user’ which are protected by ‘oauth2’ adapter.

  1. Where can I read about this? There is no documentation at zend framework or apigility sites about such code flow.

  2. What to do if access_token will expire? As you can see, I was sending ‘password’ grant_type.

  3. Can I rename or delete oauth_users table and use instead my ‘users’ table?

1 Like
2
  1. Where to store access_token?

That depends and where you’ll be using it. Store the complete token data in some sort of cache that your Client implementation can access.

  1. Where can I read about this? There is no documentation at zend framework or apigility sites about such code flow.

OAuth2 is a standardized authorization framework. ZF and Apigility are just implementing that framework in this case for the Authorization Server and Resource Server, respectively. Further, it is your Client implementation that uses Authorization Server to fit your needs (e.g. the Password grant type as you’ve shown). Why would the Authorization Server or Resource Server implementation instruct you on how you can implement your Client? There are just too many use-cases…

There are countless resources out there to help you learn OAuth2. You cannot depend on ZF to document unrelated technologies.

  1. What to do if access_token will expire? As you can see, I was sending ‘password’ grant_type.

That’s what the refresh_token is for. When the access_token expires, you can use the refresh_token value with the Refresh token grant type to get a new access_token without user interaction. If the refresh_token is not available (e.g., cleared cache), the user must login again as if they had never had an access_token.

  1. Can I rename or delete oauth_users table and use instead my ‘users’ table?

This is a question related to the Authorization Server implementation (presumably zf-oauth2 based on your question). I’m not particularly familiar with that package but the answer to your question is likely, “yes”. However, that means that you likely will need to also modify some of that implementation code or config or both to achieve that.

I’m most familiar with the league/oauth2-server and the zendframework/zend-expressive implementation. There, you can implement the necessary interfaces to “reuse” an existing “users” table.

I’m relatively certain that something similar can be done using zf-oauth2 and/or Apigility but you’ll have to dig in to figure out how. I wonder if the UserId Provider documention will help. I’m sure you’ll be able to get it done.

1 Like
3

Definitely good answer! I have forgotten that OAuth2 implementation divides in two parts: server and client. At current moment I am viewing source code of thephpleague/oauth2-client. Thank you!

4

that’s some not-bad documentation right there :grinning:

1 Like