Is OAuth2 supported in Homer11?

[josh-hook]

Hey! I've been using Homer7 for quite a while and have been looking at upgrading to Homer11.
I've been struggling to get OAuth2 flow working with Microsoft Entra ID - I'm just seeing 401s on the endpoints after the OAuth redirects all complete.

It seems like in Homer7 the Identity provider would redirect to GET /api/v3/oauth2/auth/:provider with an auth code, but in Homer11 this endpoint has become GET /api/v4/auth/oauth2/:provider/callback. The Homer11 endpoint then only reads username from the query string instead of an auth code.

Is OAuth2 fully supported, or is it currently a stub / on the roadmap?
(and if on the roadmap then happy to contribute a PR if welcome :) )

[rdunmire-ievolve]

I'm seeing the same thing here. Deploying a new Homer 11 instance with Authentik as the IdP. The login proceeds to authenticate with the IdP, redirects to the homer 11 callback with token and then HTTP 401. I've enabled debug logging but I do not see any logs indicating a problem with authentication in homer. Any advice?

Docker instance variables:

  HOMER_COORDINATOR_OAUTH2_PROVIDER_ENABLE: "true"
  HOMER_COORDINATOR_OAUTH2_PROVIDER_NAME: "authentik"
  HOMER_COORDINATOR_OAUTH2_PROVIDER_POSITION: "1"
  HOMER_COORDINATOR_OAUTH2_PROVIDER_TYPE: "oauth2"
  HOMER_COORDINATOR_OAUTH2_PROVIDER_PROVIDER_NAME: "Authentik"
  HOMER_COORDINATOR_OAUTH2_PROVIDER_URL: "https://auth.url.local/application/o/authorize/?client_id=homer-ui&response_type=code&scope=openid%20email&redirect_uri=https%3A%2F%2Fhomer.url.local%2Fapi%2Fv4%2Fauth%2Foauth2%2Fauthentik%2Fcallback"
  HOMER_COORDINATOR_OAUTH2_PROVIDER_CALLBACK_URL: "https://homer.url.local/?oauth=1" 

Client browser:

HTTP GET 302 https://homer.url.local/api/v4/auth/oauth2/authentik/callback?code=!redacted!&state=
HTTP GET 200 https://homer.url.local/?oauth=1&token=!redacted!
HTTP GET 200 https://homer.url.local/api/v4/auth/providers
HTTP GET 401 https://homer.url.local/api/v4/dashboards
HTTP GET 401 https://homer.url.local/api/v4/me

Authentik log:

{
"flow": "b06003730729436c8af0f04149a0f0aa",
"scopes": "email openid",
"http_request": {
"args": {
"scope": "openid email",
"client_id": "homer-ui",
"redirect_uri": "https://homer.url.local/api/v4/auth/oauth2/ievolve/callback",
"response_type": "code"
},
"path": "/api/v3/flows/executor/default-provider-authorization-explicit-consent/",
"method": "GET",
"request_id": "dc8545b9396f47198431e63d27f57771",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36 Edg/148.0.0.0"
},
"authorized_application": {
"pk": "!redacted!",
"app": "authentik_core",
"name": "Sipcapture",
"model_name": "application"
}
}
User
{
"pk": 0,
"email": "!redacted!",
"username": "!redacted!"
}

[adubovikov]

Lets us check it ASAP!

[adubovikov]

So. Thanks you for reports:

there are two separate issues showed up in this thread.

First, after OAuth the UI lands on callback_url with a short-lived token in the query string. That value is not a JWT. The UI must call POST /api/v4/auth/oauth2/token with {"token":"..."} and use data.token as Authorization: Bearer .... Putting the query token directly in Authorization causes 401 on /me and dashboards.

Second, the coordinator only enables OAuth when coordinator.oauth2_provider is set up for the authorization code flow: client_id, auth_url, token_url, redirect_url, profile_url, and either client_secret (if use_pkce is false) or use_pkce true for a public client. A single pre-built url field is no longer enough.

Use examples/homer-coordinator-oauth2-code-flow.sample.json

{
  "coordinator": {
    "oauth2_provider": {
      "enable": true,
      "name": "authentik",
      "position": 10,
      "type": "oauth2",
      "provider_name": "Authentik",
      "client_id": "homer-ui",
      "client_secret": "REPLACE_WITH_SECRET_OR_OMIT_IF_USE_PKCE",
      "auth_url": "https://auth.example.com/application/o/authorize/",
      "token_url": "https://auth.example.com/application/o/token/",
      "redirect_url": "https://homer.example.com/api/v4/auth/oauth2/authentik/callback",
      "profile_url": "https://auth.example.com/application/o/userinfo/",
      "scopes": ["openid", "email", "profile"],
      "use_pkce": true,
      "callback_url": "https://homer.example.com/",
      "auto_redirect": false,
      "skip_auto_provision": false,
      "admin_groups": ["homer-admins"],
      "group_claim": "groups"
    }
  }
}

and docs/AUTH_LDAP_AND_OAUTH.md as references.

Docker-style overrides use names like HOMER_COORDINATOR_OAUTH2_PROVIDER_CLIENT_ID, ..._AUTH_URL, ..._TOKEN_URL, and so on.

The redirect URI registered at the IdP must match redirect_url exactly (same path and provider name as in /api/v4/auth/oauth2//callback). OAuth state and one-time tokens are in memory, so multiple coordinator instances behind a load balancer need sticky sessions or a shared store.

Upgrade to a build that includes both the UI token exchange and the server-side code flow, then align IdP and env with the docs above.

https://github.com/sipcapture/homer/releases/tag/11.0.219

Thank you again and have a nice evening!

[rdunmire-ievolve]

Hi @adubovikov,

Thank you for the quick update. I can confirm that 11.0.219 and adding the following env vars for the docker deployment is working with Authentik. Now I just need to figure out how to deal with the admin_groups and env vars (Our admin group has a space in the name 'VoIP Admin').

HOMER_COORDINATOR_OAUTH2_PROVIDER_CLIENT_ID: "homer-ui"
HOMER_COORDINATOR_OAUTH2_PROVIDER_AUTH_URL: "https://authentik.url.local/application/o/authorize/"
HOMER_COORDINATOR_OAUTH2_PROVIDER_TOKEN_URL: "https://authentik.url.local/application/o/token/"
HOMER_COORDINATOR_OAUTH2_PROVIDER_PROFILE_URL: "https://authentik.url.local/application/o/userinfo/"
HOMER_COORDINATOR_OAUTH2_PROVIDER_REDIRECT_URL: "https://homer.url.local/api/v4/auth/oauth2/authentik/callback"
HOMER_COORDINATOR_OAUTH2_PROVIDER_USE_PKCE: "true"
HOMER_COORDINATOR_OAUTH2_PROVIDER_ADMIN_GROUPS: "VoIP Admin" <- Not working for me

Best Regards!

[adubovikov]

Let me check that I can do here

[adubovikov]

We have pushed a new release. Please test it and enable debug-level logging to verify that your groups are correctly populated in the response from your provider.

https://github.com/sipcapture/homer/releases/tag/11.0.220

[rdunmire-ievolve]

Thanks adubovikov.

2026-05-18T17:46:17Z DBG oauth2 admin group check provider=authentik group_claim=groups claim_present=false parsed_groups=[] admin_groups="[VoIP Admin]" admin_match=false

My IdP response from the Authentik admin portal but as you can see above the log indicates the group_claim is not found.

{ "iss": "https://authentik.url.local/application/o/authentik/", "sub": "rdunmire@redacted", "aud": "homer-ui", "exp": 1779122748, "iat": 1779120948, "auth_time": 1779120948, "acr": "goauthentik.io/providers/oauth2/default", "email": "rdunmire@redacted", "email_verified": true, "name": "Robert Dunmire", "given_name": "Robert", "family_name": "Dunmire", "preferred_username": "rdunmire", "nickname": "rdunmire", "groups": [ "SIPCapture Users", "VoIP Admin" ] }

[rdunmire-ievolve]

I think I figured it out. I had to add 'profile' to the oauth2 scopes.

HOMER_COORDINATOR_OAUTH2_PROVIDER_SCOPES: "openid email profile"

2026-05-18T18:13:21Z DBG oauth2 admin group check provider=authentik group_claim=groups claim_present=true parsed_groups="VoIP Admin SIPCapture Users]" admin_groups="[VoIP Admin]" admin_match=true

Thanks for your help!

[adubovikov]

Enjoy your Homer :-)

[adubovikov]

@josh-hook please let us know if the path fixed your issue as well.

[adubovikov]

and yes, any PR are welcome :-)

[josh-hook]

Hey @adubovikov this is working for me now, thank you!

[josh-hook]

Hey @adubovikov sorry another question - I'm running multiple replicas of the coordinator, but I notices the oauth state is cached in memory (https://github.com/sipcapture/homer/blob/homer11/src/coordinator/handlers/oauth_state.go#L20). Which means that if I reload and hit another replica that I didn't login with, then it rejects me with:

{"error":{"type":"https://api.homer/errors/invalid_argument","title":"Bad Request","status":400,"detail":"Invalid or expired OAuth2 state"}}

Am I reading this correctly?
Wondering if it would make sense to persist this to the SQLite DB which is used for the DuckLake catalog, or support some external cache (e.g. Redis)

[adubovikov]

no, by design it doesn't support multiple coordinators with oauth.