Support for OAuth public clients (native apps) #9635

New Issue

GiteaMirror · 2025-11-02T08:45:03-06:00

GiteaMirror commented

2025-11-02 08:45:03 -06:00

Originally created by @hickford on GitHub (Sep 29, 2022).

The OAuth spec defines two types of client, confidential and public, however Gitea assumes all clients to be confidential.

OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to
maintain the confidentiality of their client credentials):

confidential
Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure client authentication using other means.

public
Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. The authorization server SHOULD NOT make assumptions about the client type.

This is a barrier to native apps using OAuth https://datatracker.ietf.org/doc/html/rfc8252

Some OAuth server implementations that assume all clients are confidential web clients will need to add an
understanding of public native app clients and the types of redirect URIs they use to support this best practice.

In particular, Gitea should record the client type https://datatracker.ietf.org/doc/html/rfc8252#section-8.4

Authorization servers MUST record the client type in the client registration details in order to identify and process requests
accordingly.

and require PKCE for public clients: https://datatracker.ietf.org/doc/html/rfc8252#section-8.1

Authorization servers SHOULD reject authorization requests from native apps that don't use PKCE by returning an error message

Originally created by @hickford on GitHub (Sep 29, 2022). The OAuth spec [defines two types of client](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1), confidential and public, however Gitea assumes all clients to be confidential. > OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to > maintain the confidentiality of their client credentials): > > confidential > Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with > restricted access to the client credentials), or capable of secure client authentication using other means. > > **public > Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.** > > The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. The authorization server SHOULD NOT make assumptions about the client type. This is a barrier to native apps using OAuth https://datatracker.ietf.org/doc/html/rfc8252 > Some OAuth server implementations that assume all clients are confidential web clients will need to add an understanding of public native app clients and the types of redirect URIs they use to support this best practice. In particular, Gitea should record the client type https://datatracker.ietf.org/doc/html/rfc8252#section-8.4 > Authorization servers MUST record the client type in the client registration details in order to identify and process requests accordingly. and require PKCE for public clients: https://datatracker.ietf.org/doc/html/rfc8252#section-8.1 > Authorization servers SHOULD reject authorization requests from native apps that don't use PKCE by returning an error message

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:45:03 -06:00

GiteaMirror closed this issue

2025-11-02 08:45:03 -06:00

GiteaMirror commented

2025-11-02 08:45:04 -06:00

@hickford commented on GitHub (Sep 29, 2022):

First step would be to add client type field to type OAuth2Application https://github.com/go-gitea/gitea/blob/main/models/auth/oauth2.go and associated forms

GitLab has a confidential option:

Confidential
Enable only for confidential applications exclusively used by a trusted backend server that can securely store the client secret. Do not enable for native-mobile, single-page, or other JavaScript applications because they cannot keep the client secret confidential.

@hickford commented on GitHub (Sep 29, 2022): First step would be to add client type field to type OAuth2Application https://github.com/go-gitea/gitea/blob/main/models/auth/oauth2.go and associated forms GitLab has a confidential option: > Confidential Enable only for confidential applications exclusively used by a trusted backend server that can securely store the client secret. Do not enable for native-mobile, single-page, or other JavaScript applications because they cannot keep the client secret confidential. ![image](https://user-images.githubusercontent.com/105314/192996007-2527843b-8078-4fe2-af31-4e1207e26be5.png)

GiteaMirror commented

2025-11-02 08:45:04 -06:00

@hickford commented on GitHub (Sep 29, 2022):

Secondly I think handleAuthorizationCode would have to implement the logic described in https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3:

ensure that the authorization code was issued to the authenticated confidential client, or if the client is public, ensure that the code was issued to "client_id" in the request,

Right now when my native app tries to authenticate, it gets error "unauthorized_client: invalid client secret".

@hickford commented on GitHub (Sep 29, 2022): Secondly I think [handleAuthorizationCode](https://github.com/go-gitea/gitea/blob/08609d439d81f65c4f691609acaa29c1c7e96757/routers/web/auth/oauth.go#L679) would have to implement the logic described in https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3: > ensure that the authorization code was issued to the authenticated confidential client, or **if the client is public, ensure that the code was issued to "client_id" in the request**, Right now when my native app tries to authenticate, it gets error "unauthorized_client: invalid client secret".

GiteaMirror commented

2025-11-02 08:45:04 -06:00

@hickford commented on GitHub (Sep 29, 2022):

@jonasfranz who originally added OAuth support https://github.com/go-gitea/gitea/pull/5378 , do you have any insight?

@hickford commented on GitHub (Sep 29, 2022): @jonasfranz who originally added OAuth support https://github.com/go-gitea/gitea/pull/5378 , do you have any insight?

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#9635