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
Comments
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 For Outline, the error message suggests that the client is configured to use To resolve this issue, you will need to ensure that the Here are the steps you can take to troubleshoot and potentially resolve the issue:
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
When I use
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?
Also I have updated my server authz to use only forward-auth (Im using caddy)
And I modified my caddy authelia to:
|
Also, my OCIS clients below (web+android are working, desktop is not)
|
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
|
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 |
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.
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 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 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 |
Are there any example clients which fluctuate between one auth method and another? |
I set the refresh frequency on a What triggers errors are simultaneous requests around the refresh window. 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?
|
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:
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:
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.
Yes, most recent commit.
With the default
With
I assume OCIS desktop needs
|
You will have to enable the - 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. |
@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 |
I do too @nick-oconnor just wondering how to properly implement that without being flogged by the gracious users. ;) |
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)
Build Information
Logs (Authelia)
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
The text was updated successfully, but these errors were encountered: