Skip to content
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

Provide a way to access Gitea API through external authentication source #23382

Open
bratekarate opened this issue Mar 9, 2023 · 3 comments
Open
Labels
topic/api Concerns mainly the API type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@bratekarate
Copy link

bratekarate commented Mar 9, 2023

Feature Description

I have the following use case: I have an authorization server running next to my Gitea instance. Gitea is not supposed to do anything related to authentication or authorization other than using session cookies or verifying tokens, i.e. through a public key from said authorization server.

Using the Web UI, this already (kind of) achieved. It is not perfect, as roles (admin role) and group memberships are still managed by Gitea. But I can live with that as long as Gitea does not work with passwords, OTPs, security keys or anything else related to authentication.

However, when using the Rest API or the container registry, things look different. I have to create an API token to get access. This in itself would be fine for me too --- although not perfect --- if there was a way to generate this token without Web UI and without sending password or TOTP.

The example in the docs (https://docs.gitea.io/en-us/api-usage/#generating-and-listing-api-tokens) suggest to either send password/TOTP via curl or use the Web UI. I think this is not enough in the long term.

I know that #13532 has been closed, but I feel the underlying issue is valid: Gitea should be functional without its own authentication capabilities, which should be optional.

It's great that Gitea provides its own, modern authentication features if no dedicated authorization server is used. However, in the long term it would be even greater if Gitea would integrate seamlessly in more complex, sophisticated security architectures.

Screenshots

No response

@bratekarate bratekarate added type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Mar 9, 2023
@davama
Copy link

davama commented Apr 13, 2023

Hello,

Was also looking at this but failed.
We also use an external authoritative server with reverse proxy authentication.

Tried to create a token with python requests.Session with all the session cookies/headers and using basicAuth but still get below which I think I can expected since the user is not managed by gitea nor is the gitea api ready for these types of setups.

{"message":"user does not exist [uid: 12, name: yourusername, keyid: 0]","url":"https://gitea.domain.net/api/swagger"}

if i dont use basicAuth i simply get

{"message":"Only signed in user is allowed to call APIs."}

Would be great to have the api follow similar authentication policies as set for the UI

thanks

@davama
Copy link

davama commented Aug 7, 2023

Was trying this again but with oauth2_client configured on gitea, which works well, but the 3rd party provider JWTs does not seem to be supported by gitea.

Only the JWTs from gitea when gitea "acts" as a oauth2 provider, do the tokens work with api.

Would be nice if the oauth2_client was extended on the api side

@stbischof
Copy link

Same need here. What must be done do get this Feature in?

@silverwind silverwind added the topic/api Concerns mainly the API label Mar 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/api Concerns mainly the API type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

4 participants