Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Latest update broke ownCloud Ocis and Outline #6904

Closed
8 tasks done
C8opmBM opened this issue Mar 15, 2024 · 22 comments
Closed
8 tasks done

Latest update broke ownCloud Ocis and Outline #6904

C8opmBM opened this issue Mar 15, 2024 · 22 comments
Labels
priority/4/normal Normal priority items status/resolved Issue is resolved either by user action or a fix type/bug/third-party Bugs with third party software, not with Authelia itself. type/duplicate Duplicate Issues type/question A question rather than a feature/bug

Comments

@C8opmBM
Copy link

C8opmBM commented Mar 15, 2024

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

@C8opmBM C8opmBM added priority/4/normal Normal priority items status/needs-triage Issues which have not expressly been classified by a team member yet type/bug/unconfirmed Unconfirmed Bugs labels Mar 15, 2024
Copy link

glime-ai bot commented Mar 15, 2024

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:

  1. 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 or client_secret_basic).

  2. 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.

  3. 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.

  4. 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.

@james-d-elliott
Copy link
Member

james-d-elliott commented Mar 16, 2024

You will need to update the clients token_endpoint_auth_method, per the log message, the blog post, and the other issues such as #6884 to client_secret_post.

@james-d-elliott james-d-elliott added type/invalid Issues/etc that are not valid or reported correctly type/duplicate Duplicate Issues type/question A question rather than a feature/bug status/resolved Issue is resolved either by user action or a fix and removed type/bug/unconfirmed Unconfirmed Bugs status/needs-triage Issues which have not expressly been classified by a team member yet labels Mar 16, 2024
@C8opmBM
Copy link
Author

C8opmBM commented Mar 16, 2024

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
        }
}

@C8opmBM
Copy link
Author

C8opmBM commented Mar 16, 2024

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

@james-d-elliott
Copy link
Member

james-d-elliott commented Mar 16, 2024

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.

@james-d-elliott james-d-elliott added type/bug/third-party Bugs with third party software, not with Authelia itself. and removed type/invalid Issues/etc that are not valid or reported correctly labels Mar 16, 2024
@C8opmBM
Copy link
Author

C8opmBM commented Mar 16, 2024

Thanks, so this needs a future update in order to work, right? Should this be updated by you (authelia) or by OCIS?

@james-d-elliott
Copy link
Member

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.

@C8opmBM
Copy link
Author

C8opmBM commented Mar 16, 2024

Great, will test it out later. Many thanks again for this amazing piece of software

@nick-oconnor
Copy link

nick-oconnor commented Mar 16, 2024

@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.

@nick-oconnor
Copy link

For reference, I think https://github.com/golang/oauth2/blob/master/internal/token.go#L228-L242 is the source of many of the issues.

@C8opmBM
Copy link
Author

C8opmBM commented Mar 16, 2024

indeed, it does not work (master). Same errors.

@james-d-elliott
Copy link
Member

james-d-elliott commented Mar 16, 2024

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.

@nick-oconnor
Copy link

nick-oconnor commented Mar 17, 2024

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...

@james-d-elliott
Copy link
Member

james-d-elliott commented Mar 17, 2024

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).

@james-d-elliott
Copy link
Member

Are there any example clients which fluctuate between one auth method and another?

@nick-oconnor
Copy link

nick-oconnor commented Mar 17, 2024

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"

@james-d-elliott
Copy link
Member

james-d-elliott commented Mar 17, 2024

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.

@C8opmBM
Copy link
Author

C8opmBM commented Mar 17, 2024

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

@james-d-elliott
Copy link
Member

james-d-elliott commented Mar 17, 2024

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

@C8opmBM
Copy link
Author

C8opmBM commented Mar 17, 2024

Sorry for my wording, indeed I was referring to the workaround for the ocis desktop issue.
Thank you, all is good 🥇

@C8opmBM C8opmBM closed this as completed Mar 17, 2024
@nick-oconnor
Copy link

@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.

@james-d-elliott
Copy link
Member

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. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/4/normal Normal priority items status/resolved Issue is resolved either by user action or a fix type/bug/third-party Bugs with third party software, not with Authelia itself. type/duplicate Duplicate Issues type/question A question rather than a feature/bug
Projects
None yet
Development

No branches or pull requests

3 participants