KNIME AP OAuth authentication flow fails

[qugu]

Hello,

I’m setting up OAuth for KNIME Server identical to how it’s proposed my @marvin.kickuth here, and it works fine for the Web UI. However, when used with the desktop application I get this error after proceeding through the browser acceptance stage:

Invalid response from authentication server: no refresh token provided!

My server setup in relation to the desktop:

com.knime.server.authentication.oauth.redirect_ports=8888,8881,8882
com.knime.server.authentication.types=OAuth
com.knime.server.authentication.oauth.token_refresh_rate=5m

The catalina auth connector:

<Context>
    <Manager pathname=""/>

    <Parameter name="com.knime.server.repository" override="false" value="/srv/knime_server"/>

    <ResourceLink global="H2UserDatabase" name="H2UserDatabase" type="javax.sql.DataSource"/>

    <Valve className="com.knime.enterprise.tomcat.authenticator.KnimeServerAuthenticator" enableSpnego="false" basicAuthPaths="/rest" formAuthPaths="/" secretKey="someSecreKey" enableOAuth="true" enableBasicAuthWithOAuth="false" oAuthConfigurationPath="<path to file>"/>
</Context>

This flow worked at some moment of playing with the config, but I cannot catch when. Enabling extra OIDC debug on the server doesn’t yield any specific pointers in the auth log file. Enabling additional logging on the desktop just shows this:

DEBUG OAuthAuthenticator              Setting allowed clock skew for token parsing to 0s
DEBUG OAuthAuthenticator              Login to 'https://app.prod.knime.internal'.
INFO  OAuthAuthenticator              Opening browser to perform authentication for 'https://app.prod.knime.internal'.
DEBUG OAuthAuthenticator              Tokens acquired.

Any help greatly appreciated!

[bruno29a]

Hi @qugu , when you run it via the Knime AP (desktop), where are you running it from? From local station? Could it be that this is the issue?

[qugu]

Hello @bruno29a, the KNIME AP runs locally on my laptop, the connection it performs to the server is via the public internet (with VPN). Just in case you’re wondering, the names shown are resolvable over this connection.

[qugu]

The issue seems to have been in the additional auth endpoint parameters: we used an older param prompt=select_account instead of the more modern one prompt=consent. And with a combo as below the issue stopped appearing and we started seeing the refresh token in all payloads:

{
...
   "additional-authorization-endpoint-parameters": "&access_type=offline&prompt=consent",
...
}

[bruno29a]

I’m glad you were able to figure it out @qugu , and thank you for sharing what the solution was.