Oauth2-server: Resource server middleware on a separate API

[eselskas]

Hi guys, great project!

I'm a bit puzzled here. I setup an auth API using your library, its working great for all the grants! Now I have another API for resources. What im trying to achieve is to have middleware in the resource API, validating the token through the auth API. From the examples I've seen (at least this one: https://github.com/thephpleague/oauth2-server/blob/master/examples/public/api.php), it seems i need the AccessTokenRepository on the resource API as well, would that mean that has to be a duplicate of whats already on the auth API. Or am i taking the wrong approach here?

Maybe I'm suppose to use the oauth2-client in this case and add my auth API as a custom provider?

Any finger pointing me in the right direction is appreciated.

P.S. Both APIs are using Slim

[Sephster]

Apologies if I'm not following your question here but I will give it a go. I think you are correct in saying that you will need to have duplicates.

The Auth Server needs the access token repository so that it can generate and issue access tokens. The Resource Server needs the access token repository so that it can verify that the access token hasn't been revoked. Both should point to the same common store.

I hope this helps!

[eselskas]

Thanks for the quick reply, that makes sense now.

Have a great day!

[eselskas]

Hi @Sephster, I wanted to follow up on the above and clarify something.

Since we have 2 separate APIs (resource & auth), we want to keep their logic completely separate and have them communicating to different databases. I have added the AccessTokenRepository to the resource API for the moment, but the concern is that if we need to modify this repository at some point and roll out the change, we will be facing some downtime since they're duplicates on both auth & resource APIs. Also, our resource API is currently aware of and querying the auth database, which is not ideal either.

Is it possible to have some endpoint on the auth server which would be able to validate the tokens that way. So the middleware on the resource API would actually make a request to the auth API via an endpoint instead of directly querying the auth DB.

Do you have any thoughts/suggestions in this case?

[mtangoo]

Is it possible to have some endpoint on the auth server which would be able to validate the tokens that way. So the middleware on the resource API would actually make a request to the auth API via an endpoint instead of directly querying the auth DB.

I do create my endpoint and do it separately as My resources are always separate from the Oauth server. So +1 for Server inbuilt API endpoint!

[Sephster]

It sounds like you want token introspection. The RFC hasn't been implemented yet but it is planned for a future release. This is the RFC if you are interested https://tools.ietf.org/html/rfc7662

[mtangoo]

Read the RFC and sounds straight forward. Follow this library norms doesn't it mean new IntrospectionRepositoryInterface and IntrospectionEntity will be needed the former having method like IntrospectionEntity validateToken(....)?

I would be happy to write the code if I get correct guidance.

[Sephster]

Sorry @mtangoo I haven't had time to read through the spec since a few months back. I would be keen to try and stick to the norms of the library as much as possible in future development though.

[mtangoo]

I would be keen to try and stick to the norms of the library as much as possible in future development though.

@Sephster I read again my comment and sounds pushy. That wasn't what I meant. It would be strange if I didn't write after hours of work. Sorry!

You do great work of abiding to the same already 👍

[Sephster]

No worries @mtangoo - I didn't think your comment was pushy at all. Thanks for the kind words and continued support of this package