Commit Graph
7 Commits
Author SHA1 Message Date
191a74d622 Record OAuth client type at registration (#21316)
The OAuth spec [defines two types of
client](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1),
confidential and public. Previously Gitea assumed 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.

 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.

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

Fixes #21299

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2022-10-24 15:59:24 +08:00
afebbf29a9 Require authentication for OAuth token refresh (#21421)
According to the OAuth spec
https://datatracker.ietf.org/doc/html/rfc6749#section-6 when "Refreshing
an Access Token"

> The authorization server MUST ... require client authentication for
confidential clients


Fixes #21418

Co-authored-by: Gusted <williamzijl7@hotmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2022-10-23 13:28:46 +08:00
e84558b093 Improve OAuth integration tests (#21390)
In particular, test explicit error responses.

No change to behaviour.

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
2022-10-12 12:22:43 +08:00
34f509eb7a Parse OAuth Authorization header when request omits client secret (#21351)
This fixes error "unauthorized_client: invalid client secret" when
client includes secret in Authorization header rather than request body.
OAuth spec permits both.

Sanity validation that client id and client secret in request are
consistent with Authorization header.

Improve error descriptions. Error codes remain the same.

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
2022-10-07 10:53:49 +08:00
M Hickford 78c15dabf3 [skip ci] Updated translations via Crowdin 2022-09-29 00:20:54 +00:00
M HickfordandGitHub 6a45a691c1 Ignore port for loopback redirect URIs (#21293)
Following https://datatracker.ietf.org/doc/html/rfc8252#section-7.3

Fixes #21285
2022-09-29 00:19:55 +02:00
M HickfordandGitHub 0e83ab8df7 Improve error descriptions for unauthorized_client (#21292)
Fixes #21282


As suggested by the [OAuth RFC](https://www.rfc-editor.org/rfc/rfc6749)
(quoted below), it's helpful to give more detail in the description

> error_description
OPTIONAL. Human-readable ASCII
[[USASCII](https://www.rfc-editor.org/rfc/rfc6749#ref-USASCII)] text
providing **additional information, used to assist the client developer
in understanding the error that occurred.**
Values for the "error_description" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E.
2022-09-28 15:10:27 -04:00