Latest update broke ownCloud Ocis and Outline
C8opmBM opened this issue · comments
Version
v4.38.2
Deployment Method
Docker
Reverse Proxy
Caddy
Reverse Proxy Version
2.7.6
Description
After updating to 4.38.x my ownCloud Ocis (desktop and android client, the web works) and Outline no longer work.
The rest of my containers work as expected after upgrade (portainer, immich, grafana, miniflux)
Please do note the said containers have been working for more than 1 year before upgradingt o 4.38.x
Reproduction
Errors shown as soon as trying to login.
Expectations
No errors.
Configuration (Authelia)
authelia:
container_name: authelia
image: authelia/authelia:4.38.2
profiles:
- backend
depends_on:
- authelia_redis
networks:
- system
- ownmedia
- social
- arrs
- authelia-internal
user: ${PUID}:${PGID}
env_file:
- ./data/authelia/.env
expose:
- 9091
volumes:
- ${CONFIGDIR}/authelia/config:/config
- ${CONFIGDIR}/authelia/secrets:/secrets
- ${LOGDIR}/authelia:/config/log/
restart: unless-stopped
authelia_redis:
container_name: authelia_redis
hostname: authelia_redis
image: redis:latest
profiles:
- backend
networks:
- authelia-internal
expose:
- 6379
user: ${PUID}:${PGID}
volumes:
- ${CONFIGDIR}/authelia/redis:/data
restart: unless-stopped
Build Information
Last Tag: v4.38.2
State: tagged clean
Branch: v4.38.2
Commit: 573e79c8d34e118195731424df15d3e2c989495e
Build Number: 27687
Build OS: linux
Build Arch: amd64
Build Compiler: gc
Build Date: Sat, 16 Mar 2024 02:33:12 +1100
Extra:
Go:
Version: go1.22.1
Module Path: github.com/authelia/authelia/v4
Executable Path: github.com/authelia/authelia/v4/cmd/authelia
Settings:
-buildmode: pie
-compiler: gc
-trimpath: true
DefaultGODEBUG: httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
CGO_ENABLED: 1
GOARCH: amd64
GOOS: linux
GOAMD64: v1
vcs: git
vcs.revision: 573e79c8d34e118195731424df15d3e2c989495e
vcs.time: 2024-03-15T15:24:32Z
vcs.modified: true
Dependencies:
authelia.com/provider/oauth2@v0.1.1 (h1:JHMWB8aieYW++7a+t3RIB0fkxcLMHyT7NUKPEAl6cls=)
filippo.io/edwards25519@v1.1.0 (h1:FNf4tywRC1HmFuKW5xopWpigGjJKiJSV0Cqo0cJWDaA=)
github.com/Azure/go-ntlmssp@v0.0.0-20221128193559-754e69321358 (h1:mFRzDkZVAjdal+s7s0MwaRv9igoPqLRdzOLzw/8Xvq8=)
github.com/Gurpartap/logrus-stack@v0.0.0-20170710170904-89c00d8a28f4 (h1:vdT7QwBhJJEVNFMBNhRSFDRCB6O16T28VhvqRgqFyn8=)
github.com/andybalholm/brotli@v1.1.0 (h1:eLKJA0d02Lf0mVpIDgYnqXcUn0GqVmEFny3VuID1U3M=)
github.com/asaskevich/govalidator@v0.0.0-20230301143203-a9d515a09cc2 (h1:DklsrG3dyBCFEj5IhUbnKptjxatkF07cF2ak3yi77so=)
github.com/authelia/jsonschema@v0.1.7 (h1:RbtTeTG7GiWIrx2A+3O+b33jr/mLlSmqGYyk1w5gLNA=)
github.com/authelia/otp@v1.0.0 (h1:X6YeBMb16CkW8fFpLBQc0ams+Ed0zw1R/5pfih/1vLU=)
github.com/beorn7/perks@v1.0.1 (h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM=)
github.com/boombuler/barcode@v1.0.1 (h1:NDBbPmhS+EqABEs5Kg3n/5ZNjy73Pz7SIV+KCeqyXcs=)
github.com/cespare/xxhash/v2@v2.2.0 (h1:DC2CZ1Ep5Y4k3ZQ899DldepgrayRUGE6BBZ/cd9Cj44=)
github.com/davecgh/go-spew@v1.1.1 (h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=)
github.com/dgraph-io/ristretto@v0.1.1 (h1:6CWw5tJNgpegArSHpNHJKldNeq03FQCwYvfMVWajOK8=)
github.com/dgryski/go-rendezvous@v0.0.0-20200823014737-9f7001d12a5f (h1:lO4WD4F/rVNCu3HqELle0jiPLLBs70cWOduZpkS1E78=)
github.com/dlclark/regexp2@v1.4.0 (h1:F1rxgk7p4uKjwIQxBs9oAXe5CqrXlCduYEJvrF4u93E=)
github.com/duosecurity/duo_api_golang@v0.0.0-20240205144049-bb361ad4ae1c (h1:xFrCg835Y/ig7iWQqyVmGFG5cd1OztnlN3rF64ltEpY=)
github.com/dustin/go-humanize@v1.0.1 (h1:GzkhY7T5VNhEkwH0PVJgjz+fX1rhBrR7pRT3mDkpeCY=)
github.com/facebookgo/stack@v0.0.0-20160209184415-751773369052 (h1:JWuenKqqX8nojtoVVWjGfOF9635RETekkoH6Cc9SX0A=)
github.com/fasthttp/router@v1.5.0 (h1:3Qbbo27HAPzwbpRzgiV5V9+2faPkPt3eNuRaDV6LYDA=)
github.com/fasthttp/session/v2@v2.5.4 (h1:SeblRaKHYQoVBjJIF1KlZD0F8QX1poA80h/KaLhNo8I=)
github.com/fsnotify/fsnotify@v1.7.0 (h1:8JEhPFa5W2WU7YfeZzPNqzMP6Lwt7L2715Ggo0nosvA=)
github.com/fxamacker/cbor/v2@v2.6.0 (h1:sU6J2usfADwWlYDAFhZBQ6TnLFBHxgesMrQfQgk1tWA=)
github.com/go-asn1-ber/asn1-ber@v1.5.5 (h1:MNHlNMBDgEKD4TcKr36vQN68BA00aDfjIt3/bD50WnA=)
github.com/go-crypt/crypt@v0.2.19 (h1:9VFKbVCuWH4cQDbjUA6fGiaHx+w0CXI19rHQGTZqESE=)
github.com/go-crypt/x@v0.2.13 (h1:YUgKO62hIcPz11ViwHZx89g/OJhOis9+kK13ZunWpS0=)
github.com/go-jose/go-jose/v4@v4.0.1 (h1:QVEPDE3OluqXBQZDcnNvQrInro2h0e4eqNbnZSWqS6U=)
github.com/go-ldap/ldap/v3@v3.4.6 (h1:ert95MdbiG7aWo/oPYp9btL3KJlMPKnP58r09rI8T+A=)
github.com/go-sql-driver/mysql@v1.8.0 (h1:UtktXaU2Nb64z/pLiGIxY4431SJ4/dR5cjMmlVHgnT4=)
github.com/go-viper/mapstructure/v2@v2.0.0-alpha.1 (h1:TQcrn6Wq+sKGkpyPvppOz99zsMBaUOKXq6HSv655U1c=)
github.com/go-webauthn/webauthn@v0.10.2 (h1:OG7B+DyuTytrEPFmTX503K77fqs3HDK/0Iv+z8UYbq4=)
github.com/go-webauthn/x@v0.1.9 (h1:v1oeLmoaa+gPOaZqUdDentu6Rl7HkSSsmOT6gxEQHhE=)
github.com/golang-jwt/jwt/v5@v5.2.1 (h1:OuVbFODueb089Lh128TAcimifWaLhJwVflnrgM17wHk=)
github.com/golang/glog@v1.2.0 (h1:uCdmnmatrKCgMBlM4rMuJZWOkPDqdbZPnrMXDY4gI68=)
github.com/golang/protobuf@v1.5.3 (h1:KhyjKVUg7Usr/dYsdSqoFveMYd5ko72D+zANwlG1mmg=)
github.com/google/go-tpm@v0.9.0 (h1:sQF6YqWMi+SCXpsmS3fd21oPy/vSddwZry4JnmltHVk=)
github.com/google/uuid@v1.6.0 (h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=)
github.com/hashicorp/go-cleanhttp@v0.5.2 (h1:035FKYIWjmULyFRBKPs8TBQoi0x6d9G4xc9neXJWAZQ=)
github.com/hashicorp/go-retryablehttp@v0.7.5 (h1:bJj+Pj19UZMIweq/iie+1u5YCdGrnxCT9yvm0e+Nd5M=)
github.com/iancoleman/orderedmap@v0.3.0 (h1:5cbR2grmZR/DiVt+VJopEhtVs9YGInGIxAoMJn+Ichc=)
github.com/jackc/pgpassfile@v1.0.0 (h1:/6Hmqy13Ss2zCq62VdNG8tM1wchn8zjSGOBJ6icpsIM=)
github.com/jackc/pgservicefile@v0.0.0-20221227161230-091c0ba34f0a (h1:bbPeKD0xmW/Y25WS6cokEszi5g+S0QxI/d45PkRi7Nk=)
github.com/jackc/pgx/v5@v5.5.5 (h1:amBjrZVmksIdNjxGW/IiIMzxMKZFelXbUoPNb+8sjQw=)
github.com/jackc/puddle/v2@v2.2.1 (h1:RhxXJtFG022u4ibrCSMSiu5aOq1i77R3OHKNJj77OAk=)
github.com/jmoiron/sqlx@v1.3.5 (h1:vFFPA71p1o5gAeqtEAwLU4dnX2napprKtHr7PYIcN3g=)
github.com/klauspost/compress@v1.17.6 (h1:60eq2E/jlfwQXtvZEeBUYADs+BwKBWURIY+Gj2eRGjI=)
github.com/knadh/koanf/maps@v0.1.1 (h1:G5TjmUh2D7G2YWf5SQQqSiHRJEjaicvU0KpypqB3NIs=)
github.com/knadh/koanf/parsers/yaml@v0.1.0 (h1:ZZ8/iGfRLvKSaMEECEBPM1HQslrZADk8fP1XFUxVI5w=)
github.com/knadh/koanf/providers/confmap@v0.1.0 (h1:gOkxhHkemwG4LezxxN8DMOFopOPghxRVp7JbIvdvqzU=)
github.com/knadh/koanf/providers/env@v0.1.0 (h1:LqKteXqfOWyx5Ab9VfGHmjY9BvRXi+clwyZozgVRiKg=)
github.com/knadh/koanf/providers/posflag@v0.1.0 (h1:mKJlLrKPcAP7Ootf4pBZWJ6J+4wHYujwipe7Ie3qW6U=)
github.com/knadh/koanf/v2@v2.1.0 (h1:eh4QmHHBuU8BybfIJ8mB8K8gsGCD/AUQTdwGq/GzId8=)
github.com/mattn/go-sqlite3@v1.14.22 (h1:2gZY6PC6kBnID23Tichd1K+Z0oS6nE/XwU+Vz/5o4kU=)
github.com/mitchellh/copystructure@v1.2.0 (h1:vpKXTN4ewci03Vljg/q9QvCGUDttBOGBIa15WveJJGw=)
github.com/mitchellh/mapstructure@v1.5.0 (h1:jeMsZIYE/09sWLaz43PL7Gy6RuMjD2eJVyuac5Z2hdY=)
github.com/mitchellh/reflectwalk@v1.0.2 (h1:G2LzWKi524PWgd3mLHV8Y5k7s6XUvT0Gef6zxSIeXaQ=)
github.com/mohae/deepcopy@v0.0.0-20170929034955-c48cc78d4826 (h1:RWengNIwukTxcDr9M+97sNutRR1RKhG96O6jWumTTnw=)
github.com/ory/herodot@v0.10.3-0.20230807143059-27cd6936499b (h1:AEUyF55UrqTuhJh72I9azACdJrRrDBBjK/XWgVxuQvY=)
github.com/ory/x@v0.0.616 (h1:iaojp7MvFW1cdirSZFK/XeuJvyhUEVXQdY61bmIOkzk=)
github.com/philhofer/fwd@v1.1.2 (h1:bnDivRJ1EWPjUIRXV5KfORO897HTbpFAQddBdE8t7Gw=)
github.com/pkg/errors@v0.9.1 (h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=)
github.com/pmezard/go-difflib@v1.0.0 (h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=)
github.com/prometheus/client_golang@v1.19.0 (h1:ygXvpU1AoN1MhdzckN+PyD9QJOSD4x7kmXYlnfbA6JU=)
github.com/prometheus/client_model@v0.5.0 (h1:VQw1hfvPvk3Uv6Qf29VrPF32JB6rtbgI6cYPYQjL0Qw=)
github.com/prometheus/common@v0.48.0 (h1:QO8U2CdOzSn1BBsmXJXduaaW+dY/5QLjfB8svtSzKKE=)
github.com/prometheus/procfs@v0.12.0 (h1:jluTpSng7V9hY0O2R9DzzJHYb2xULk9VTR1V1R/k6Bo=)
github.com/redis/go-redis/v9@v9.5.1 (h1:H1X4D3yHPaYrkL5X06Wh6xNVM/pX0Ft4RV0vMGvLBh8=)
github.com/savsgio/gotils@v0.0.0-20240303185622-093b76447511 (h1:KanIMPX0QdEdB4R3CiimCAbxFrhB3j7h0/OvpYGVQa8=)
github.com/sirupsen/logrus@v1.9.3 (h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ=)
github.com/spf13/cobra@v1.8.0 (h1:7aJaZx1B85qltLMc546zn58BxxfZdR/W22ej9CFoEf0=)
github.com/spf13/pflag@v1.0.5 (h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA=)
github.com/stretchr/testify@v1.9.0 (h1:HtqpIVDClZ4nwg75+f6Lvsy/wHu+3BoSGCbBAcpTsTg=)
github.com/tinylib/msgp@v1.1.9 (h1:SHf3yoO2sGA0veCJeCBYLHuttAVFHGm2RHgNodW7wQU=)
github.com/trustelem/zxcvbn@v1.0.1 (h1:mp4JFtzdDYGj9WYSD3KQSkwwUumWNFzXaAjckaTYpsc=)
github.com/valyala/bytebufferpool@v1.0.0 (h1:GqA5TC/0021Y/b9FG4Oi9Mr3q7XYx6KllzawFIhcdPw=)
github.com/valyala/fasthttp@v1.52.0 (h1:wqBQpxH71XW0e2g+Og4dzQM8pk34aFYlA1Ga8db7gU0=)
github.com/wneessen/go-mail@v0.4.1 (h1:m2rSg/sc8FZQCdtrV5M8ymHYOFrC6KJAQAIcgrXvqoo=)
github.com/x448/float16@v0.8.4 (h1:qLwI1I70+NjRFUR3zs1JPUCgaCXSh3SW62uAKT1mSBM=)
golang.org/x/crypto@v0.21.0 (h1:X31++rzVUdKhX5sWmSOFZxx8UW/ldWx55cbf08iNAMA=)
golang.org/x/net@v0.22.0 (h1:9sGLhx7iRIHEiX0oAJ3MRZMUCElJgy7Br1nO+AMN3Tc=)
golang.org/x/oauth2@v0.18.0 (h1:09qnuIAgzdx1XplqJvW6CQqMCtGZykZWcXzPMPUusvI=)
golang.org/x/sync@v0.6.0 (h1:5BMeUDZ7vkXGfEr1x9B4bRcTH4lpkTkpdh0T/J+qjbQ=)
golang.org/x/sys@v0.18.0 (h1:DBdB3niSjOA/O0blCZBqDefyWNYveAYMNF1Wum0DYQ4=)
golang.org/x/term@v0.18.0 (h1:FcHjZXDMxI8mM3nwhX9HlKop4C0YQvCVCdwYl2wOtE8=)
golang.org/x/text@v0.14.0 (h1:ScX5w1eTa3QqT8oi6+ziP7dTV1S2+ALU0bI+0zXKWiQ=)
google.golang.org/genproto/googleapis/rpc@v0.0.0-20231106174013-bbf56f31fb17 (h1:Jyp0Hsi0bmHXG6k9eATXoYtjd6e2UzZ1SCn/wIupY14=)
google.golang.org/grpc@v1.59.0 (h1:Z5Iec2pjwb+LEOqzpB2MR12/eKFhDPhuqW91O+4bwUk=)
google.golang.org/protobuf@v1.33.0 (h1:uNO2rsAINq/JlFpSdYEKIZ0uKD/R9cpdv0T+yoGwGmI=)
gopkg.in/yaml.v3@v3.0.1 (h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=)
Logs (Authelia)
OUTLINE LOGS
add level=error
add method=POST
add msg=Access Request failed with error: Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The request was determined to be using 'token_endpoint_auth_method' method 'client_secret_post', however the OAuth 2.0 client registration does not allow this method. The registered client with id 'outline' is configured to only support 'token_endpoint_auth_method' method 'client_secret_basic'. Either the Authorization Server client registration will need to have the 'token_endpoint_auth_method' updated to 'client_secret_post' or the Relying Party will need to be configured to use 'client_secret_basic'.
OCIS desktop LOGS:
Client Authentication failed with more than one known authentication method included in the request when the authorization server policy does not permit this. The client authentication methods detected were 'client_secret_basic', 'client_secret_post'.
Logs (Proxy / Application)
No response
Documentation
No response
Pre-Submission Checklist
-
I agree to follow the Code of Conduct
-
This is a bug report and not a support request
-
I have read the security policy and this bug report is not a security issue or security related issue
-
I have either included the complete configuration file or I am sure it's unrelated to the configuration
-
I have either included the complete debug / trace logs or the output of the build-info command if the logs are not relevant
-
I have provided all of the required information in full with the only alteration being reasonable sanitization in accordance with the Troubleshooting Sanitization reference guide
-
I have checked for related proxy or application logs and included them if available
-
I have checked for related issues and checked the documentation
Please note this response was created using generative AI leveraging previously available information from the repository. This information may be helpful however it is our strong recommendation that you carefully consider the information before blindly applying it.
Based on the information provided and the error logs from both Outline and OCIS desktop clients, it seems the issue is related to the token_endpoint_auth_method
used for client authentication in the OAuth 2.0 flow. The error messages indicate a mismatch between the authentication method expected by the Authelia server and the method used by the clients.
For Outline, the error message suggests that the client is configured to use client_secret_post
as the authentication method, but the Authelia server expects client_secret_basic
. Similarly, for the OCIS desktop client, the error indicates that more than one authentication method was detected (client_secret_basic
, client_secret_post
), which is not permitted by the Authelia server's policy.
To resolve this issue, you will need to ensure that the token_endpoint_auth_method
configured for your clients matches the method expected by the Authelia server. This configuration is typically done in the OAuth 2.0 client registration settings on the Authelia server and the client application settings.
Here are the steps you can take to troubleshoot and potentially resolve the issue:
-
Check Authelia's OAuth 2.0 Client Registration Settings: Review the OAuth 2.0 client registration settings on the Authelia server for the clients in question (Outline and OCIS desktop). Ensure that the
token_endpoint_auth_method
is set to the method that the clients are configured to use (client_secret_post
orclient_secret_basic
). -
Update Client Configuration: If the Authelia server is configured to use a specific authentication method that differs from what the clients are using, update the client configuration to match the server's expected method. This might involve changing client settings or updating the OAuth 2.0 client registration on the Authelia server.
-
Review Authelia Documentation: Consult the Authelia documentation related to OAuth 2.0 integration and client registration to ensure that your configuration aligns with the recommended practices. Specifically, look for information on configuring
token_endpoint_auth_method
and client authentication methods. -
Check for Authelia Updates: Since you mentioned the issue started after updating to Authelia 4.38.x, check the Authelia release notes or GitHub issues for any known issues or changes related to OAuth 2.0 client authentication in the 4.38.x releases. It's possible that a change in the latest version affected the authentication flow for your clients.
If after taking these steps the issue persists, consider reaching out to the Authelia support community or filing an issue on the Authelia GitHub repository with detailed information about your configuration and the troubleshooting steps you've taken.
This comment was generated by Glime.
Thanks and sorry for the duplicate, somehow I could not find it when searched the first time.
I have solved 2 clients (Outline and OCIS android) however the desktop client won't work no matter the options I use.
For example, when I use token_endpoint_auth_method: client_secret_basic
it shows as if it uses multiple auth methods:
Client Authentication failed with more than one known authentication method included in the request which is not permitted. The registered client with id 'xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69' and the authorization server policy does not permit this malformed request. The
token_endpoint_auth_method
methods determined to be used were 'client_secret_basic', 'client_secret_post'.
When I use token_endpoint_auth_method: client_secret_post
The request was determined to be using 'token_endpoint_auth_method' method 'client_secret_basic', however the OAuth 2.0 client registration does not allow this method. The registered client with id 'xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69' is configured to only support 'token_endpoint_auth_method' method 'client_secret_post'. Either the Authorization Server client registration will need to have the 'token_endpoint_auth_method' updated to 'client_secret_basic' or the Relying Party will need to be configured to use 'client_secret_post'.
Is there a bug maybe?
Or perhaps could this be related to my borrowed "hack" for the desktop client used in caddy auth uri line below?
Does this line needs to be modified since I modified the uri /api/authz/forward-auth/ ?
auth.{$DOMAIN} {
# This is necessary until Authelia learns prompt handling. It's planned for beta 7 (https://www.authelia.com/roadmap/active/openid-connect/#beta-7)
uri /api/oidc/authorization replace &prompt=select_account%20consent ""
reverse_proxy authelia:9091
}
Also I have updated my server authz to use only forward-auth (Im using caddy)
server:
address: 0.0.0.0:9091
endpoints:
authz:
forward-auth:
implementation: 'ForwardAuth'
authn_strategies:
- name: 'HeaderProxyAuthorization'
schemes:
- 'Basic'
- name: 'CookieSession'
And I modified my caddy authelia to:
(restricted-access) {
forward_auth authelia:9091 {
uri /api/authz/forward-auth/
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
}
}
Also, my OCIS clients below (web+android are working, desktop is not)
WORKING
- client_id: ownCloud-web
client_name: ownCloud web client
public: true
authorization_policy: two_factor
redirect_uris:
- https://cloud.domain.net/
- https://cloud.domain.net/oidc-callback.html
- https://cloud.domain.net/oidc-silent-redirect.html
consent_mode: implicit
NOT WORKING
- client_id: xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69
client_name: ownCloud desktop client
public: false
client_secret: 'UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh'
authorization_policy: two_factor
redirect_uris:
- http://127.0.0.1
- http://localhost
scopes:
- openid
- groups
- email
- profile
- offline_access
grant_types:
- refresh_token
- authorization_code
response_types:
- code
token_endpoint_auth_method: client_secret_post
consent_mode: implicit
WORKING
- client_id: e4rAsNUSIUs0lF4nbv9FmCeUkTlV9GdgTLDH1b5uie7syb90SzEVrbN7HIpmWJeD
client_name: ownCloud Android app
public: false
client_secret: 'dInFYGV33xKzhbRmpqQltYNdfLdJIfJ9L5ISoKhNoT9qZftpdWSP71VrpGR9pmoD'
authorization_policy: two_factor
scopes:
- openid
- groups
- email
- profile
- offline_access
grant_types:
- refresh_token
- authorization_code
response_types:
- code
response_modes:
- form_post
- query
- fragment
redirect_uris:
- oc://android.owncloud.com
token_endpoint_auth_method: client_secret_basic #here with basic/default auth endpoint
consent_mode: implicit
Client Authentication failed with more than one known authentication method included in the request which is not permitted. The registered client with id 'xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69' and the authorization server policy does not permit this malformed request. The
token_endpoint_auth_method
methods determined to be used were 'client_secret_basic', 'client_secret_post'.
Ahhh, the client is not compliant with the spec, there is an escape hatch I forgot to add though in #6910. But this is enough to reclassify this as a third party bug.
See: https://datatracker.ietf.org/doc/html/rfc6749#section-2.3
The client MUST NOT use more than one authentication method in each
request.
Thanks, so this needs a future update in order to work, right? Should this be updated by you (authelia) or by OCIS?
Thanks, so this needs a future update in order to work, right? Should this be updated by you (authelia) or by OCIS?
This is technically a bug with the OCIS desktop app I think you said it was, basically it shouldn't include it in both the header and body, but we're adding an escape hatch in 4.38.3 which we intended to have available in 4.38.0. When enabled allows clients which. You can try it now with master
.
Great, will test it out later. Many thanks again for this amazing piece of software
@james-d-elliott Unfortunately this doesn't work. I think the early return https://github.com/authelia/oauth2-provider/blob/master/client_authentication.go#L85-L87 needs to be removed.
For reference, I think https://github.com/golang/oauth2/blob/master/internal/token.go#L228-L242 is the source of many of the issues.
indeed, it does not work (master). Same errors.
Show the client config.
@james-d-elliott Unfortunately this doesn't work. I think the early return https://github.com/authelia/oauth2-provider/blob/master/client_authentication.go#L85-L87 needs to be removed.
I'm afraid there is a test case which shows otherwise, this is probably not the case. In fact on closer inspection that return occurs before the noted error can ever return.
I just stepped through the tests which are correctly exercising allow_multiple_auth_methods
. What I didn't understand is that the intent is to allow both auth methods when present within the same request. I assumed that the intention was to allow requests with either auth method.
I think what's occurring is that some clients are not consistent as to which type of auth they use for each request, i.e. some requests use basic auth and some use post auth, not that both are present within the same request. I'll see if I can get a packet capture of the issue. If that is the case, IMHO the cleanest solution is for token_endpoint_auth_method
to accept a list of allowed auth methods.
The state of these clients is horrible. I'm sorry you're having to deal with this. I'm getting late-2000's JavaScript vibes...
No that's not the intent. It allows misbehaving clients which include BOTH methods in the same request as you figured out. The client in go works well prior to these changes, only tries a second one when an error occurs, which is fine for this purpose.
I am not sure if I want to go down the path of allowing multiple methods per client as it's going to make future efforts impossibly jank (especially a list of allowed ones will make it impossibly jank to support dynamic registration). Maybe another escape hatch which ignores the auth type entirely provided it satisfies a single method.. but I really don't like either of these options for security reasons. Relying Parties themselves really need to fix this. But I'll think about it.
The state of OAuth 2.0 and implementation understanding is generally rather horrible, many implementations do not properly honor very important rules (like redirect_uri
matching must NOT involve pattern matching, just normalized URL matches). This is probably mostly because of how broad the spec is, think it's roughly 30 specs plus 15 OIDC specs that have been formalized (i.e. not draft). There are even elements of the specs themselves that are flawed (not being able to request an audience). Most things are clear if you read, but some things are a bit strange unless you very carefully read them (i.e. client id and secret MUST be URL escaped before encoding them as base64 for the client_secret_basic
method, but some clients including Cloudflare do NOT do this).
Are there any example clients which fluctuate between one auth method and another?
I set the refresh frequency on a oauth2-proxy
(uses golang/oauth2) instance to 1m (w/ cookie client-side storage) and did a packet capture. Sessions are being successfully created and refreshed. Refresh requests only include basic auth and the refresh completes successfully. Clearly my issue is separate from the one reported here. My apologies for the confusion.
What triggers errors are simultaneous requests around the refresh window. oauth2-proxy
attempts the refresh flow simultaneously which is documented behavior. As expected, one of them succeeds and the rest fail with token not found. For each request that fails, the golang/oauth2 client re-tries the request with post auth (per link in my 2nd comment) and Authelia correctly logs the unauthorized method. I mistook the token_endpoint_auth_method
messages as being the same as those in this issue.
I saw the error messages and assumed I had something mis-configured which wasn't the case. I do not think any changes are required.
I do not have a client which sends both types of auth in the same request so I am unable to verify if the new flag works. @C8opmBM Your log has the most recent commit right?
level=info msg="Authelia untagged-v4.38.2 (master, 32424bf) is starting"
For transparency since the issue was confirmed fixed I pushed another change to this area of the code, it was just removing the context from both sides (consistency in client receiver functions). But it does not affect the behavior.
Also yes, if oauth2-proxy does that it's expected to receive that error if it uses the same token twice. Once the token is used the refresh token is no longer valid as a new one is issued.
Per RFC6749 Section 6:
The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.
Which the revoking of a previously used refresh token is also recommended in the OAuth 2.0 Security Best Current Practice document. There is also a recommendation that a potentially fraudulent use of a refresh token (like in this instance) would cause a complete revocation of all associated tokens which we have not implemented yet in fear that it would cause major issues for these misbehaving clients:
Refresh token rotation: the authorization server issues a new refresh token with every access token refresh response. The previous refresh token is invalidated but information about the relationship is retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach. The authorization server cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token. This stops the attack at the cost of forcing the legitimate client to obtain a fresh authorization grant.
We will probably add an "opt-in" to enforce this second part on a per-client basis.
hello, and I am a bit confused if the issue has been fixed (the said escape hatch), however the issue seems still present in my setup.
Client Authentication failed with more than one known authentication method included in the request which is not permitted.
Yes, most recent commit.
add level=info
add msg=Authelia untagged-v4.38.2 (master, 2970dd8) is starting
With the default token_endpoint_auth_method: client_secret_basic
add level=error
add method=POST
add msg=Access Request failed with error: The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. Client Authentication failed with more than one known authentication method included in the request which is not permitted. The registered client with id 'xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69' and the authorization server policy does not permit this malformed request. The `token_endpoint_auth_method` methods determined to be used were 'client_secret_basic', 'client_secret_post'.
add path=/api/oidc/token
With token_endpoint_auth_method: client_secret_post
add level=error
add method=POST
add msg=Access Request failed with error: Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The request was determined to be using 'token_endpoint_auth_method' method 'client_secret_basic', however the OAuth 2.0 client registration does not allow this method. The registered client with id 'xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69' is configured to only support 'token_endpoint_auth_method' method 'client_secret_post'. Either the Authorization Server client registration will need to have the 'token_endpoint_auth_method' updated to 'client_secret_basic' or the Relying Party will need to be configured to use 'client_secret_post'.
add path=/api/oidc/token
I assume OCIS desktop needs client_secret_basic
since the android one works with the default auth method.
Again my config below. Web and Android do work, the desktop throwing the above errors when alternating the auth method:
- client_id: ownCloud-web #Works
client_name: ownCloud web client
public: true
authorization_policy: two_factor
redirect_uris:
- https://cloud.redacted.net/
- https://cloud.redacted.net/oidc-callback.html
- https://cloud.redacted.net/oidc-silent-redirect.html
consent_mode: implicit
- client_id: xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69 #Not working
client_name: ownCloud desktop client
public: false
client_secret: 'UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh'
authorization_policy: two_factor
redirect_uris:
- http://127.0.0.1
- http://localhost
scopes:
- openid
- groups
- email
- profile
- offline_access
grant_types:
- refresh_token
- authorization_code
response_types:
- code
response_modes:
- form_post
- query
- fragment
token_endpoint_auth_method: client_secret_basic
consent_mode: implicit
- client_id: e4rAsNUSIUs0lF4nbv9FmCeUkTlV9GdgTLDH1b5uie7syb90SzEVrbN7HIpmWJeD #Works
client_name: ownCloud Android app
public: false
client_secret: 'dInFYGV33xKzhbRmpqQltYNdfLdJIfJ9L5ISoKhNoT9qZftpdWSP71VrpGR9pmoD'
authorization_policy: two_factor
scopes:
- openid
- groups
- email
- profile
- offline_access
grant_types:
- refresh_token
- authorization_code
response_types:
- code
response_modes:
- form_post
- query
- fragment
redirect_uris:
- oc://android.owncloud.com
token_endpoint_auth_method: client_secret_basic
consent_mode: implicit
You will have to enable the allow_multiple_auth_methods
option for that misbehaving client (the one including multiple auth methods in a single request). Also it's not fixed, something that's working correctly can't be fixed, a workaround for the unfixed element (OCIS) has been added.
- client_id: xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69 #Not working
client_name: ownCloud desktop client
public: false
client_secret: 'UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh'
authorization_policy: two_factor
redirect_uris:
- http://127.0.0.1
- http://localhost
scopes:
- openid
- groups
- email
- profile
- offline_access
grant_types:
- refresh_token
- authorization_code
response_types:
- code
response_modes:
- form_post
- query
- fragment
token_endpoint_auth_method: client_secret_basic
allow_multiple_auth_methods: true
consent_mode: implicit
Sorry for my wording, indeed I was referring to the workaround for the ocis desktop issue.
Thank you, all is good 🥇
@james-d-elliott Yep makes total sense. Any client which stuffs oauth state into cookies is asking to have problems with token events.
I like the extension to that, i.e. revoking refresh tokens on re-use, as that flow should never occur for well-behaved clients. I just switched all my oauth2-proxy
instances over to redis which supports queuing requests during token events and the issue disappeared.
I like the extension to that, i.e. revoking refresh tokens on re-use, as that flow should never occur for well-behaved clients. I just switched all my oauth2-proxy instances over to redis which supports queuing requests during token events and the issue disappeared.
I do too @nick-oconnor just wondering how to properly implement that without being flogged by the gracious users. ;)