Jump to content
You're invited! Join our 4.6 Live Event on ZOOM 6/24 ×

Community

Creating an OAuth2 plugin for a third party application


CoffeeCake
 Share

Go to solution Solved by CoffeeCake,

Recommended Posts

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?

Link to comment
Share on other sites

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 by Paul E.
Link to comment
Share on other sites

  • Solution

@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 by Paul E.
Link to comment
Share on other sites

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.

train fixing GIF

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

Link to comment
Share on other sites

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."

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy