Thursday, 4 January 2018

Keycloak, Apache and OpenID Connect

mod_auth_openidc makes it easy to secure your applications running in Apache or when Apache is used as a reverse proxy. It can be used both for enabling SSO to web applications as well as to secure RESTful services. For more details check out our documentation as well as the guides from mod_auth_openidc.


  1. It might be worth mentioning that it's not possible to require roles in the Apache httpd auth config since in openidconnect mode it treats the access token as opaque and keycloak does not put resource_access or realm_access anywhere else. As such, every user of a realm will have access to a service "secured" with this mod and keycloak.
    There are dirty workarounds with mapping into userinfo and such.

    The author of mod_auth_openidc considers this a feature since it is following the spec and would not consider making the access token transparent in openidconnect with a flag either.

    So yeah, you can use it, but it will bring you plenty of pain.

    1. That's a shame. A "proxy" option to secure a service really does need to have at least some simple way of mapping claims to permissions. Or at least the ability to send the relevant claims in headers so the application/service can do it.

    2. It does put the access token in an env var, so an underlying app can pull it apart if it needs to. However, potentially unauthorized people now have access to more attack surface than they need to because you can't just require claims from the access_token in this apache httpd module.

      Something simple like "secure this directory or this oidc-unaware webapp so only people with role X can access it" is not possible without jumping through extra hoops (namely mapping into UserInfo or id_token, which carries its own problems and bugs inside Keycloak).

  2. The author says: the access token in an OIDC flow is not meant for the client (=mod_auth_openidc) but it uses it to access resources elsewhere.

    But realm info/rolses can be put in and obtained from the id_token or userinfo endpoint and used to map to access permissions in a straightforward way for any OIDC provider including Keycloak.

  3. see for the suggested approach


Please only add comments directly associated with the post. For general questions use the Keycloak user mailing list.