Creating an OAuth2 plugin for a third party application

[CoffeeCake]

Hi,

I'm trying to create an OAuth2 plugin for a third party application to use IPS 4.5 as an authentication server via OAuth2. I'm following this guide:

https://invisioncommunity.com/developers/rest-api

It's a bit unclear what the request to call api/core/me should look like and my attempts so far have not been successful. After agreeing to login using IPS, clicking continue, I'm redirected to the third-party application, which returns an error: invalid_client. This is generic and I'm not sure coming from IPS. There is nothing logged within the REST/API log in the ACP.

After getting redirected to the third party app, I'm sending a request to https://<hostname>/api/core/me with the header "Authorization" and the value "Bearer <ACCESS_TOKEN>"

Has anyone tried this that would know if I'm headed in the right direction here?

[CoffeeCake]

So, a bit of debugging more and trying to wrap my head around this, I've confirmed that the error is coming from the Generate Access Token Endpoint, and the first condition is failing:

/* Get the client */
try
{
        $obj->client = \IPS\Api\OAuthClient::load( $clientId );
        if ( !$obj->client->enabled )
        {
                throw new \OutOfRangeException;
        }
}
catch ( \OutOfRangeException $e )
{
        throw new \IPS\Login\Handler\OAuth2\Exception( 'invalid_client' );
}

Looking to see where this client thing is enabled, and I've verified that $clientId is empty. Hrmmmm....

Edited August 27, 2020 by Paul E.

[bfarber]

The code you highlighted appears to be coming from oauth/token/index.php is that right? If so, that is the /token endpoint for an OAuth2 request and should not be getting hit when performing a generic /api/ request?

[CoffeeCake]

@bfarber: Yes, I'm doing an OAuth2 request. Ultimately, if I understand the workflow correctly, application redirects to oauth/authorize, user logs in, redirected back to application, which creates an access token (hitting oauth/token) and then application requests /api/core/me to get id/username/email, etc. for the authenticated user.

After much debugging and injecting outputs through both IPS and the third party application, I found that the post for the token call was failing because I had defined the token URI as example.com/oauth/token instead of example.com/oauth/token/. I'm not sure if this is a peculiarity of nginx and my web server configuration with php-fpm, but when I added the trailing slash, the script would receive the post request with the expected variables. Prior to that, the script would only see the post request with no elements provided.

Now, I'm at the point where the token is given, yet the third-party application is complaining that the id is not being sent from the call to /api/core/me which has the token in the Authentication header. Further along the chain, yet still not quite there. Working on adding debug code to IPS to see exactly what's being returned by /api/core/me.

Edited August 28, 2020 by Paul E.

[CoffeeCake]

Further along, I've confirmed that IPS is sending the needed data to the third-party application. The issue may be in how the JSON is formatted vs. what the third-party expects.

[CoffeeCake]

Aaaaaannnnd resolved. Not sure if that trailing slash thing is a bug. But, fixed my issue with the third-party. That was a journey.

[CoffeeCake]

Should /core/me return the member's e-mail address? The API documentation suggests it does, yet it does not.

[CoffeeCake]

And lastactivity is returned in unixtime rather than formatted time. Also, secondary groups are not returned by /core/me. I've created a support ticket, but logging here in case anyone else goes crazy for a weekend trying to figure out why things that should work aren't.

Edited August 30, 2020 by Paul E.

[bfarber]

On 8/30/2020 at 12:52 AM, Paul E. said:

Should /core/me return the member's e-mail address? The API documentation suggests it does, yet it does not.

Email address should be available if you made the request with "email" as a scope.

On 8/30/2020 at 1:04 AM, Paul E. said:

And lastactivity is returned in unixtime rather than formatted time. Also, secondary groups are not returned by /core/me. I've created a support ticket, but logging here in case anyone else goes crazy for a weekend trying to figure out why things that should work aren't.

lastActivity should not be a timestamp - if it is, that would be a bug and should be reported, thanks.

[CoffeeCake]

Just now, bfarber said:

Email address should be available if you made the request with "email" as a scope.

lastActivity should not be a timestamp - if it is, that would be a bug and should be reported, thanks.

I reported both issues as a bug (via support request--the bug tracker doesn't allow me to post new ones anymore), and an additional one where secondary groups are not returned as documented by /core/me.

To retrieve the e-mail address, I found that I did not need to update the scope, but rather simply include /core/me/email as allowed in the existing scope (which is not called "email").

It may be that the documentation needs to be updated to say "must include 'email' as the name of your scope" or "must allow /core/me/email."