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 ConfigMap
s 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
- test: add test for 2329 expand-env This adds a test for https://github.com/authelia/authelia/issues/2329#issuecomment-1414201785 — committed to authelia/authelia by james-d-elliott a year ago
- test: add test for 2329 expand-env (#4870) This adds a test for https://github.com/authelia/authelia/issues/2329#issuecomment-1414201785 — committed to authelia/authelia by james-d-elliott a year ago
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 tohttps://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 apreferred_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.
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.