Having trouble with OAuth setup

[HelloWorld]

Hello people,

I am trying to setup OAuth right now, but having some trouble with it.

My setup :

• One IPB forum, version 4.3, on the subdomain forum.xxx.com (with SSL).
• One Symfony website, on the subdomain www.xxx.com (with SSL).

I want my users to be able to login on my Symfony website using their IPB credentials. So far, it was working seamlessly with IPSConnect. People could access a login page on the Symfony website, enter their IPB credentials there, and be logged in: everything was working fine.

With OAuth, things are a bit different. When users click the login link, they are redirected to forum.xxx.com/oauth/authorize. This is OK for me. Now, there are two scenarii: 

• It works when I am already logged in on forum.xxx.com.
  1. I get to the website on www.xxx.com.
  2. I click the login link.
  3. This redirects to forum.xxx.com/oauth/authorize, with the correct client ID and secret being transmitted (transparent for the user).
  4. I grant access to the website.
  5. I am redirected to the website.
  6. → This worked, I am logged in and can see my nickname on the home page.
• It does not work when I am not already logged in on forum.xxx.com.
  1. I get to the website on www.xxx.com.
  2. I click the login link.
  3. This  redirects to forum.xxx.com/oauth/authorize, with the correct client ID and secret being transmitted (transparent for the user).
  4. On this URL, I see the classic login form (nickname + password), which I fill and submit with correct credentials.
  5. There, I am redirected once again to forum.xxx.com/oauth/authorize, but the client ID seems to be missing.
  6. → An error saying "Invalid Client ID" (code 3S361/1) is displayed.

I would expect IPB, in the second scenario, to log me in on the forum, then allow me to grant access to the website. But it does not work that way. Is there something that I am doing wrong?

Something is troubling me, in the second scenario.

• Between steps 2 and 3 (see above), when I click the login link, the website redirects (302) to https://forum.xxx.com/oauth/authorize/?response_type=code&client_id=(clientid)&scope=profile&redirect_uri=(redirecturi), which in turns redirects (301) to forum.xxx.com/oauth/authorize.
• But between steps 4 and 5 (see above), when I submit the form, I am redirected straight to forum.xxx.com/oauth/authorize, as this is the action attribute of the form tag :

<form accept-charset="utf-8" method="post" action="https://forum.xxx.com/oauth/authorize/" data-controller="core.global.core.login">

Could this, maybe, be of any relevance?

If some of you managed to get this to work, I am all ears and begging for your help :)

Thanks everyone!

[HelloWorld]

Hi everyone,

Noone with an idea on that matter?

Thank you for your help :)

[HelloWorld]

I started "debugging" IPS OAuth code. I found something that may be relevant, in case someone stops by and wants to help!

1. I get to my website and click on the login link : www.xxx.com/login/ips4
→ Status code: redirect 302
→ To: https://forum.xxx.com/oauth/authorize/?response_type=code&client_id=(id)&scope=profile&redirect_uri=(uri)

2. This, in turn, redirects:
→ Status code: redirect 301
→ To: https://forum.xxx.com/oauth/authorize/

At this stage, I thought: "How does IPB know the client ID, as it is not in the GET nor the POST parameters of this latest query?"

In fact, before redirecting from step 1 to step 2, the client ID is saved in the database, in the table core_oauth_authorize_prompts, which primary key is the session ID. This session ID can be found in the ips4_IPSSessionFront cookie. So, at step 2, IPB gets the client ID from the database.

3. I am not logged in yet, so I fill and submit the login form, which redirects to https://forum.xxx.com/oauth/authorize/.

4. Now, I am supposed to view the screen that allows me to grant authorization to my website.

One slight problem there: as I switched from non-logged in to logged in status, between steps 3 and 4, the ips4_IPSSessionFront cookie is reset with a new value... which means that at step 4, IPB cannot find the client ID in the query request, nor in the database, as my new session ID does not exist in the DB.

This may be the issue for the "Invalid Client ID". What do you think? Could this be a bug? Or a bad configuration on my board / server?

Please let me know what you think!

[HelloWorld]

I managed to get this to work – but I needed to make a few changes to IPB code, so I will submit that as a bug and let them decide whether this is one or not.

In oauth/authorize/index.php:

public function prompt( $requestedPromptType, $loggedIn )
{
    // ...
    $success->process();

    // Add this
    $_SESSION['old_IPSSessionFront'] = \IPS\Session::i()->id;

    // ...
}

// Line ~375
$loggedIn = FALSE;
if ( !isset( \IPS\Request::i()->client_id ) )
{
    try
    {
        // Add this
        if (isset($_SESSION['old_IPSSessionFront'])) {
            \IPS\Db::i()->update( 'core_oauth_authorize_prompts', array( 'session_id' => \IPS\Session::i()->id ), array( 'session_id=?', $_SESSION['old_IPSSessionFront'] ) );
            unset($_SESSION['old_IPSSessionFront']);
        }

        // Existing code
        $row = \IPS\Db::i()->select( '*', 'core_oauth_authorize_prompts', array( 'session_id=?', \IPS\Session::i()->id ) )->first();
        // ...
    }
}

@Staff : feel free to close if you want.

[ZackL]

I wanted to thank you for your debugging work on this. It's saved me a headache. ?

Edit for posterity:

Contacted support about this issue and they say it'll be fixed in the next release.