oauth2-server Add introspection implementation

Off the back of the pull request comments laid out here https://github.com/thephpleague/oauth2-server/pull/869. I thought I would take the comments on board, as I am keen to start using the introspection features already started by @fetzi.

Jul 20 '18 16:07 StevePorter92

Thanks for this @StevePorter92 and apologies for not picking this up yet. I plan on setting some time aside this weekend to pick up some of the pending PRs. Thanks for your patience and thank you for your contribution

Jul 27 '18 11:07 Sephster

Hey @Sephster, don't suppose you have had a chance to cast your eye of this?

Sep 14 '18 12:09 StevePorter92

Sorry @StevePorter92 I have not yet. I have been working on numerous things for the library over the past week or so. I'm focussing on getting the PKCE changes into version 8 at the moment as there was at one time 3 separate pull requests trying to address some implemenation concerns around that. Once I've finished this (which is now fairly close to be honest), I will look at getting this reviewed. Thanks for your patience

Sep 17 '18 19:09 Sephster

Hey @Sephster, no worries at all! 😄

Sep 17 '18 20:09 StevePorter92

Hi @StevePorter92. Thanks for your patience here. A couple of things spring to mind at the moment which I think are missing from this at the moment:

The token doesn't have to be a JWT. Although this server provides JWT bearer tokens out the box, implementers are free to use other formats. I don't think this is handled at the moment so will need to be addressed.
I don't believe the introspection end point is protected. We should be protecting this with some form of authentication as it should not be available to public clients. Note that some implementations will put this end point behind a firewall internally so we have to take this into consideration as well.
I don't see how the resource server is using this end point. Can you clarify this.

Thanks for your efforts to date. I hope these comments are useful. Cheers!

Sep 21 '18 20:09 Sephster

Hey @Sephster! Really appreciate the feedback, will get to your comments as soon as possible

Oct 03 '18 20:10 StevePorter92

Hi @StevePorter92 - any updates on this PR? I'm happy to pick this up in your absence if you're snowed under.

Nov 09 '18 11:11 Sephster

Hey @Sephster. Sorry for the delay. Little snowed under recently yes. I've got a few updates I'll check-in hopefully this evening to address your comments. Thanks for the support!

Nov 10 '18 13:11 StevePorter92

Added some changes to address your comments @Sephster.

The Introspector now validates through a IntrospectionValidator interface. I've moved all of the token logic to a BearerTokenValidator class. This should give implementers the freedom to validate introspection requests for other formats.

I'm a little unsure as to the best way to get the resource server to use our new endpoint so could do with being pointed in the right direction. My current line of thought is to create a AuthorizationValidators\IntrospectionValidator class. I think this will just need the URL of the introspection endpoint as well as any information required for authentication?

Also a little unsure on the best way to protect this new endpoint. What are your thoughts on this?

Thanks again.

Nov 11 '18 12:11 StevePorter92

So, I'm currently sort of in the need of introspection because I want to use Express Gateways OAuth 2.0 Introspection functionality with my Lumen 5.8 + Passport based Microservice - any eta on the implementation of Introspection?

Mar 13 '19 11:03 ThaDaVos

Sorry for the pings but, anything @StevePorter92 or @Sephster ?

Mar 13 '19 11:03 ThaDaVos

It is awaiting review from myself. I will get to it eventually but don't have a firm timeline for this at present sorry.

Mar 13 '19 13:03 Sephster

Ah okay, currently got it half working by using a separate package - only running into one problem which is that the Authorization header seems to be required to have to validation in the BearerTokenValidator succeed, even though it is in the request body... Apparently it seems Express Gateway doesn't put it into the Header so I'm a bit stuck and I don't know if this is a Bug in the BearerTokenValidator or not because Express Gateway talks about using a combination of Client_Id:Client_secret as Token Validation Value or something

Mar 13 '19 14:03 ThaDaVos

So when can we expect this to be implemented @Sephster - cause currently it's a big stopper when you want to use the Microservices Architecture with Laravel or Lumen

Or do you have an alternative/workaround? I tried overriding the ResourceServer so I can return a custom validator (actually just a modified version of the BearerTokenValidator so it looks in the body instead of the header - where it should actually check when using introspection - but... a few needed class members are private... authorizationValidator and accessTokenRepository

Mar 13 '19 15:03 ThaDaVos

So when can we expect this to be implemented @Sephster - cause currently it's a big stopper when you want to use the Microservices Architecture with Laravel or Lumen

Or do you have an alternative/workaround? I tried overriding the ResourceServer so I can return a custom validator (actually just a modified version of the BearerTokenValidator so it looks in the body instead of the header - where it should actually check when using introspection - but... a few needed class members are private... authorizationValidator and accessTokenRepository

Mar 14 '19 08:03 ThaDaVos

As @sephster said, there isn't currently a timeline for this feature @dvdbot.

Introspection can be achieved with laravel through passport and https://github.com/designmynight/laravel-oauth-introspect-middleware.

Currently what's outstanding is finding a sensible way for the resource server to use introspection. We also need to consider authentication.

@sephster, when you come to review this, let me know if there's anything I can pick up.

Mar 14 '19 08:03 StevePorter92

Will do, thanks @StevePorter92. I should have some free time this evening. Unfortunately @dvdbot, this isn't just a case of reviewing the code. I also need to familiarise myself with the RFC to ensure it is conforming to spec which is why PRs such as this take longer than a normal bug fix. I won't be drawn on timescales as I find they are nearly always optimistic. Hope you understand and sorry I can't give a more definitive answer than that

Mar 14 '19 08:03 Sephster

@StevePorter92 and @Sephster - I've got it working for the moment as follows: I copied the controller from the Laravel Introspection package, then I copied the token validation part from the BearerTokenValidator into the controller, added a public key variable which gets instantiated as follows

$this->publicKey = new CryptKey('file://'.Passport::keyPath('oauth-'. 'public' .'.key'), null, null);

Above I stole from somewhere inside the Passport package :joy:

Now I can at least introspect

Mar 14 '19 11:03 ThaDaVos

I'm just wondering why you put the introspection logic in the authorization server? Shouldn't it be in the resource server? Then create a new validator IntrospectionValidator maybe then apply same logic as the BearerTokenValidator but except it doesn't require to be have Authorization header?

Aug 07 '19 07:08 canfone

Is this feature still being actively considered for development?

Jan 15 '20 12:01 arondeparon

Yes. Rough plan is to get Device Code in place and then this. January is super busy for me as I need to do tax returns etc but will be picking up speed on this soon. Cheers

Jan 15 '20 12:01 Sephster

How is the progress?