authelia: OIDC: public client - "Client authentication failed [...]. The requested OAuth 2.0 Client does not exist."

Bug Report

Description

I’m using Authelia as my OIDC identity provider for ownCloud Infinite Scale (oCIS). oCIS is a public client, so my Authelia configuration looks like this:

 ...
    clients: 
      - id: owncloud
        description: ownCloud
        public: true
        secret: ''
        authorization_policy: one_factor
        audience:
          - user:mypersonaluser
        redirect_uris:
          - https://cloud.mydomain.tld/index.php/apps/openidconnect/redirect
          - https://cloud.mydomain.tld/oidc-callback.html
          # ! when OpenID Connect Front-Channel Logout 1.0 is implemented
          # - https://cloud.mydomain.tld/index.php/apps/openidconnect/logout
        scopes:
          - openid
          - email
          - profile

On login, I am directed to Authelia, but I’m getting a HTTP 401 response code:

{
  "error" : "invalid_client",
  "error_description" : "Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The requested OAuth 2.0 Client does not exist."
}

and this log output:

Error occurred in NewAuthorizeRequest: invalid_client
github.com/ory/x/errorsx.WithStack
    github.com/ory/x@v0.0.250/errorsx/errors.go:38
github.com/ory/fosite.(*Fosite).NewAuthorizeRequest
    github.com/ory/fosite@v0.40.2/authorize_request_handler.go:288
github.com/authelia/authelia/v4/internal/handlers.oidcAuthorization
    github.com/authelia/authelia/v4/internal/handlers/handler_oidc_authorization.go:21
github.com/authelia/authelia/v4/internal/middlewares.NewHTTPToAutheliaHandlerAdaptor.func1
    github.com/authelia/authelia/v4/internal/middlewares/http_to_authelia_handler_adaptor.go:113
github.com/authelia/authelia/v4/internal/middlewares.AutheliaMiddleware.func1.1
    github.com/authelia/authelia/v4/internal/middlewares/authelia_context.go:51
github.com/fasthttp/router.(*Router).Handler
    github.com/fasthttp/router@v1.4.1/router.go:414
github.com/authelia/authelia/v4/internal/middlewares.LogRequestMiddleware.func1
    github.com/authelia/authelia/v4/internal/middlewares/log_request.go:14
github.com/valyala/fasthttp.(*Server).serveConn
    github.com/valyala/fasthttp@v1.28.0/server.go:2239
github.com/valyala/fasthttp.(*workerPool).workerFunc
    github.com/valyala/fasthttp@v1.28.0/workerpool.go:223
github.com/valyala/fasthttp.(*workerPool).getCh.func1
    github.com/valyala/fasthttp@v1.28.0/workerpool.go:195
runtime.goexit
    runtime/asm_amd64.s:1371" stack="github.com/authelia/authelia/v4/internal/handlers/handler_oidc_authorization.go:23          oidcAuthorization
github.com/authelia/authelia/v4/internal/middlewares/http_to_authelia_handler_adaptor.go:113 NewHTTPToAutheliaHandlerAdaptorfunc1
github.com/authelia/authelia/v4/internal/middlewares/authelia_context.go:51                  AutheliaMiddleware.func1.1
github.com/fasthttp/router@v1.4.1/router.go:414                                              (*Router).Handler
github.com/authelia/authelia/v4/internal/middlewares/log_request.go:14                       LogRequestMiddleware.func1
github.com/valyala/fasthttp@v1.28.0/server.go:2239                                           (*Server).serveConn
github.com/valyala/fasthttp@v1.28.0/workerpool.go:223                                        (*workerPool).workerFunc
github.com/valyala/fasthttp@v1.28.0/workerpool.go:195                                        (*workerPool).getCh.func1
runtime/asm_amd64.s:1371                                                                     goexit"

I looked more than twice at my ownCloud configuration. The client_id matches, and I don’t know what’s wrong ATM. The request URI looks like this:

https://auth.mydomain.tld/api/oidc/authorize?client_id=owncloud&redirect_uri=https://cloud.mydomain.tld/oidc-callback.html&response_type=code&scope=openid email profile&state=3902f8bfaf274d46925253fbb4854618&code_challenge=Z7UiTOYqCoTCM6vtuhcAVjDpXEyv95L0HxRZUmdxR10&code_challenge_method=S256&response_mode=query

As I’m running Authelia in K8s, I have restarted the pod several times (deleting it and letting the replica-set do its work), I have checked that all ConfigMaps are up-to-date, etc.

Expected Behaviour

I should be able to see Authelia’s log-in screen and log in.

Reproduction Steps

I’m not sure whether this has to do with the public client type or not. For additional information have a look at owncloud/ocis#2445.

Additional Information

Versions

Authelia: 4.30.4 oCIS: 1.11.0 (Technical Preview) HTTP/3 was used for all requests (not sure if this was relevant).

The documentation on OIDC states that beta2 was not implemented as of yet, but version 4.30.X is already released. There is some confusion about this as well…

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 28 (20 by maintainers)

Commits related to this issue

Most upvoted comments

I published a full and detailed description of how to set up and configure ownCloud Infinite Scale (oCIS) OpenID Connect authentication to Authelia on my blog:

https://helgeklein.com/blog/owncloud-infinite-scale-with-openid-connect-authentication-for-home-networks/

I found this ticket via googling about to try the same combination, @coucoulala, I too would very much appriciate if you could post your working config for myself and others stumbling upon this thread Thank you very much!

Just tested the latest owncloud/ocis:linux-amd64 and the account provisioning / login works.

@james-d-elliott Thank you for your investigations (and Authelia in general). After you’ve reopened the issue, I verified again the jwt id_token obtained in the login flow with with the tool on https://jwt.davetonge.co.uk/ and it’s valid. As visible in the attached request logs, it’s basically all working until a request ist made to https://ocis.example.org/ocs/v1.php/cloud/capabilities?format=json. Edit: Looking in the Owncloud logs it’s failing because the jwt doesn’t contain a preferred_username claim. I’ve set Owncloud to auto provision accounts and to my undertstanding it’s expecting this claim. {"level":"warn","service":"storage","pkg":"rhttp","host":"127.0.0.1","method":"GET","uri":"/data/index.cs3/unique.github.com.owncloud.ocis.accounts.pkg.proto.v0.Account.Mail/mail@example.org","url":"/data/index.cs3/unique.github.com.owncloud.ocis.accounts.pkg.proto.v0.Account.Mail/mail@example.org","proto":"HTTP/1.1","status":404,"size":0,"start":"19/Oct/2021:11:49:24 +0000","end":"19/Oct/2021:11:49:24 +0000","time_ns":629028,"time":"2021-10-19T11:49:24Z","message":"http"} {"level":"error","service":"proxy","query":"mail eq 'mail@example.org'","time":"2021-10-19T11:49:24Z","message":"account not found"}{"level":"warn","service":"proxy","time":"2021-10-19T11:49:24Z","message":"Missing preferred_username claim"} {"level":"error","service":"proxy","error":"{\"id\":\"com.owncloud.api.accounts\",\"code\":400,\"detail\":\"preferred_name '' must be at least the local part of an email\",\"status\":\"Bad Request\"}","time":"2021-10-19T11:49:24Z","message":"Could not get user by claim"}

@georglauterbach Yes I guess it’s better to wait for GA and improved documentation. ocis_requests

Hey @georglauterbach I’m still investigating this, I have combed through the code to see if there was anything obvious but cannot see anything. Everything in fosite and authelia indicates what I suggested above. I have been rather busy lately and have yet had the chance to replicate it, however I will attempt to this week.

Looking at the trace this appears to be a unmatched ClientID:

https://github.com/ory/fosite/blob/d022bbc2b45fd603cb12575e28bbe884170bf788/authorize_request_handler.go#L286-L290

This is most likely to occur if it’s not configured on oCIS properly, or if oCIS isn’t providing the client_id as required in the query params. If you’d like we can make a build which logs the request to the respective endpoint and we can see.