Non-confidential OAuth 2 clients should not be issued a client secret at all #12922

New Issue

GiteaMirror · 2025-11-02T10:25:05-06:00

GiteaMirror commented

2025-11-02 10:25:05 -06:00

Originally created by @archer-321 on GitHub (Apr 27, 2024).

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

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.

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

Originally created by @archer-321 on GitHub (Apr 27, 2024). ### 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 > 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. ### 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

GiteaMirror added the type/bug label 2025-11-02 10:25:05 -06:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12922