Use mod_auth_openidc 2.2+ with session info and access type public

[solsson]

Before the support for https://github.com/pingidentity/mod_auth_openidc/wiki/Single-Page-Applications we've used a special Location that sort of supports session info:

    Header always set Access-Control-Allow-Credentials "true"
    Header always set Access-Control-Allow-Origin "null"
    ErrorDocument 401 "{\"authenticated\": false }"
    ErrorDocument 404 "{\"authenticated\": true }"

And to refresh we were using jQuery this way:

  jquery.ajax({
    url: opt.path,
    crossDomain: true,
    xhrFields: {
      withCredentials: true
    },
  })

Also we've always used Access Type "confidential" for the openid-connect client in Keycloak, but that seems to block token based auth.

[solsson]

Public vs. confidential is clearly described in https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.0/html/server_administration_guide/sso_protocols:

Another important aspect of this flow is the concept of a public vs. a confidential client. Confidential clients are required to provide a client secret when they exchange the temporary codes for tokens. Public clients are not required to provide this client secret. Public clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client. HTML5/JavaScript clients always have to be public clients because there is no way to transmit the client secret to them in a secure manner.

There's no reason to change the default, as Keycloak requires the field "Valid Redirect URIs" to be set. Field description:

Valid URI pattern a browser can redirect to after a successful login or logout. Simple wildcards are allowed i.e. 'http://example.com/'. Relative path can be specified too i.e. /my/relative/path/. Relative paths are relative to the client root URL, or if none is specified the auth server root URL is used. For SAML, you must set valid URI patterns if you are relying on the consumer service URL embedded with the login request.

I found this article that explains OpenID Connect.

[zandbelt]

Why not use the binaries from: https://github.com/pingidentity/mod_auth_openidc/releases/download/v2.3.0/libapache2-mod-auth-openidc_2.3.0-1.jessie.1_amd64.deb

I'd actually prefer that but we have downstream builds that depend on the structure from https://hub.docker.com/_/httpd/ and I thought (guessed actually) that the binaries wouldn't install there. I can give it a try.

[solsson]

@zandbelt It's been very useful to be able to test with mod_auth_openidc directly from a github commit, so would it be possible to publish libcjose0 -dev whenever there's a new version of the cjose package?

[zandbelt]

I see; well my release builds will always produce libjose and libjose-dev packages here: https://mod-auth-openidc.org/download

[edit]: That is until the required libjose release is in the relevant distro's.

[solsson]

Thanks. I'll keep the build updated using those downloads.

Might have been wrong about using binaries. See https://github.com/Reposoft/openidc-keycloak-test/pull/18. Do you think https://github.com/Reposoft/openidc-keycloak-test/pull/18/commits/748c2e206317d24fed382922392f28708f950fcc is an ok way to run the binaries, or do we risk instability when they are not compiled using --with-apxs2=/usr/local/apache2/bin/apxs?

[zandbelt]

That's safe: assuming you're using binaries for the target platform (jessie in this case) and you haven't modified the stock apache binaries on there, these packages are built using --with-apxs2=/usr/local/apache2/bin/apxs on the very same platform.