You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gitea supports non-confidential (public) OAuth 2 clients. Those clients regularly receive a client ID but no client secret, as they are not expected to be able to keep it secret.
While Gitea has support for non-confidential clients, it always issues a client secret. This becomes a problem when considering the following sections of RFC 6749:
Section 3.2.1
Confidential clients or other clients issued client credentials MUST
authenticate with the authorization server as described in
Section 2.3 when making requests to the token endpoint.
Section 4.1.3
If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
[...]
The authorization server MUST:
o require client authentication for confidential clients or for any
client that was issued client credentials (or with other
authentication requirements),
The way I interpret these sections (please correct me if I'm wrong), the specification requires that the client sends its secret if it has one, even if it is non-confidential.
In practice, this means that non-confidential applications would still have to hard-code the client secret in the application (which might not be possible with some frameworks).
I'm unsure what the best way to address this problem is, as starting to follow the specification by requiring the client secret would break all current non-confidential OAuth applications.
To test this, I created a non-confidential application on https://try.gitea.io with the app ID 31dacb06-140b-4fb9-bbde-be0c508c4d99. It was assigned a secret.
Description
Gitea supports non-confidential (public) OAuth 2 clients. Those clients regularly receive a client ID but no client secret, as they are not expected to be able to keep it secret.
While Gitea has support for non-confidential clients, it always issues a client secret. This becomes a problem when considering the following sections of RFC 6749:
Section 3.2.1
Section 4.1.3
The way I interpret these sections (please correct me if I'm wrong), the specification requires that the client sends its secret if it has one, even if it is non-confidential.
In practice, this means that non-confidential applications would still have to hard-code the client secret in the application (which might not be possible with some frameworks).
I'm unsure what the best way to address this problem is, as starting to follow the specification by requiring the client secret would break all current non-confidential OAuth applications.
To test this, I created a non-confidential application on https://try.gitea.io with the app ID
31dacb06-140b-4fb9-bbde-be0c508c4d99
. It was assigned a secret.Gitea Version
1.23.0+dev-226-gc93eefb42b
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
I tested this on https://try.gitea.io, but this should apply to all instances.
Database
None
The text was updated successfully, but these errors were encountered: