Additional Token handling after AuthorizatonServer::respondToAccessTokenRequest

[JasonTheAdams]

I have a scenario where I want to do additional handling of the access token before the API response is sent. I'm not finding a good way to be able to hook into AuthorizatonServer::respondToAccessTokenRequest at a point where the token is available. Ultimately it provides the response, but by then the token is in JWT form.

I thought that I may be able to use this line — https://github.com/thephpleague/oauth2-server/blob/master/src/Grant/ClientCredentialsGrant.php#L42 — but it just passes the $request. Maybe it would be enough to pass the $accessToken above as well?

To be clear, I don't want to change anything in that process; I just want the access token so I can use it elsewhere. I'm open to any suggestions. Otherwise, if I'm right about the event, I'll make a PR to include the token in it.

Thanks!

[Sephster]

I don't think there is a way to do this in the library. Can you provide a bit more information about the nature of the additional handling you want to do?

[JasonTheAdams]

In this project I'm only using client credentials, and have two resource tables — Clients & Websites. Clients is a resource (think business client) which has a one-to-one with the OAuth Client table. So each OAuth Client will be connected to one Client. In fact, in the API, when one creates the Client resource, it's also creating an OAuth Client and then connecting the two (the Client table has a oauth_client_id column).

From there, each Client has many Websites, in the same way each OAuth Client has many Access Tokens. So the relationship continues such that each Access Token corresponds to a single Website.

What I'd like to do in the API, then, is that when an AccessToken is requested and created, it also creates a Website and connects the two. That said, if the token expires I don't want the website to expire. So perhaps instead of using the same endpoint I should break it into two: One which returns a JWT Access Token, and another which creates the Website. The Website endpoint would require the JWT to be provided.

I've really been trying to figure out how kosher it is to connect the OAuth tables with my resource tables. They run in parallel in a number of ways, but I know they should be distinct in most ways.

Anyway, there's my scenario. Open to any thoughts! Thanks! :)

[Sephster]

I think there is something not quite right about your architecture. The clients shouldn't be as coupled to your resources as they are.

Take Twitter and the many third party applications that connect to the platform as an example. If a client requests access for a given user's account, it must know in advance which user it is requesting information for. How does this work in your implementation if you are creating resources when you are requesting access?

In addition, because the twitter user's account exists entirely independently of the third party application, when the third party app no longer requires its access token or doesn't renew it, it is of no concern to the Twitter account as it has no real explicit coupling with the third party app in question.

Apologies if I'm not following your example properly but my feeling is that the coupling between your clients and your resources is what is causing you problems. I would focus on trying to remove that if possible. Hope this helps

[Sephster]

@JasonTheAdams is there anything else I can help you with in regards to this issue? Many thanks

[JasonTheAdams]

Hi @Sephster, thanks for checking in!

Per your feedback I decided to hire a consultant to talk over the OAuth to Resource details. I learned that I was being overly clever with the authentication and resources. There is always a contact point of some type between the OAuth and Resources, but it ought to be minimal, clear, and very secure.

In this case, the Website resource is now connected to the OAuth Client — since we're not using users (just client credentials) we need an alternative resource. The Access Token will give the each website access to only the resources under a specific Website resource. The Website id is included in the JWT so it can be authenticated in each request. That's the lockdown and it makes sense now.

All that to say this is all set. This lib is working perfectly and I'm moving forward without issue. I'll go ahead and close this. Thanks so much for your guidance!

[Sephster]

No problem. Sounds like you ended up with a great solution! Glad to be of help

[renepupil]

@Sephster I think I have a valid use case: Logging

After calling respondToAccessTokenRequest, I want to log the access token id as we want to log creations/revokations of access tokens. I know there is the RequestEvent::ACCESS_TOKEN_ISSUED event, but only because this token is issued does NOT mean a successful response is generated, hence it only makes sense logging the successful creation of the access token after getting the complete response from respondToAccessTokenRequest.

Also caching with listener for RequestEvent::ACCESS_TOKEN_ISSUED seems bad design...

I wouldn't even know how to get the unencrypted access_token from the bearer token, as both, access token and request token are encrypted?

From my point respondToAccessTokenRequest seems unnecessarily wrapped. It would be way more user friendly if this would just return the ResponseType and BearerToken had a getter for the access token...

[Sephster]

Awesome, thanks for this feedback @renepupil