forgejo/forgejo

Fork 700

feat: OAuth Device Authorization Grant #4830

New issue

Open

opened 2024-08-05 21:41:53 +02:00 by abueide · 10 comments

abueide commented

2024-08-05 21:41:53 +02:00

Needs and benefits

Would love to be able to use git-credential-oauth on my headless devices via the device authorization grant flow.

Opening this issue to get the conversation, would love to get started on implementing this myself as my first contribution to forgejo. If anyone has any tips/pointers or considerations before I start it is very appreciated!

Feature Description

Implement https://www.rfc-editor.org/rfc/rfc8628

Screenshots

No response

### Needs and benefits Would love to be able to use [git-credential-oauth](https://github.com/hickford/git-credential-oauth) on my headless devices via the device authorization grant flow. Opening this issue to get the conversation, would love to get started on implementing this myself as my first contribution to forgejo. If anyone has any tips/pointers or considerations before I start it is very appreciated! ### Feature Description Implement https://www.rfc-editor.org/rfc/rfc8628 ### Screenshots _No response_

👍 5

abueide added the

enhancement/feature

label

2024-08-05 21:41:53 +02:00

Gusted commented

2024-08-06 00:43:14 +02:00

Owner

Did you try to use this? This should work out of the box since 63ab92d797 and there's documentation for this https://forgejo.org/docs/latest/user/oauth2-provider/#git-authentication

Did you try to use this? This should work out of the box since 63ab92d7971e4931e98f014f2c5385d2242fa780 and there's documentation for this https://forgejo.org/docs/latest/user/oauth2-provider/#git-authentication

abueide commented

2024-08-06 02:10:54 +02:00

Author

Did you try to use this? This should work out of the box since 63ab92d797 and there's documentation for this https://forgejo.org/docs/latest/user/oauth2-provider/#git-authentication

forgive me if I'm wrong, but are you sure that device authorization is supported? I don't see anything mentioned in the docs that says that I can ssh into a headless machine, initiate an oauth flow, copy the link onto another device and be able to authorize the original headless ssh session. The callback url goes to localhost on the device with the browser, i'm unsure how the token is supposed to get back to the headless ssh session.

> Did you try to use this? This should work out of the box since 63ab92d7971e4931e98f014f2c5385d2242fa780 and there's documentation for this https://forgejo.org/docs/latest/user/oauth2-provider/#git-authentication > forgive me if I'm wrong, but are you sure that device authorization is supported? I don't see anything mentioned in the docs that says that I can ssh into a headless machine, initiate an oauth flow, copy the link onto another device and be able to authorize the original headless ssh session. The callback url goes to localhost on the device with the browser, i'm unsure how the token is supposed to get back to the headless ssh session.

Gusted commented

2024-08-06 02:12:55 +02:00

Owner

Ah sorry, I think I misread your post. Yeah that's indeed not yet supported.

Gusted added the

forgejo/security

label

2024-08-06 02:20:02 +02:00

abueide commented

2024-08-06 02:43:05 +02:00

Author

I also would like to implement printing out a QR code in the terminal that links to the oauth url like tailscale does with its --qr parameter. Then you can just snap a pic with the phone and authorize in a mobile browser. Will start poking around and trying to learn more about the forgejo oauth code.

Gusted commented

2024-08-09 17:56:30 +02:00

Owner

Will start poking around and trying to learn more about the forgejo oauth code.

Feel free to join the development room in Matrix if you have any questions.

> Will start poking around and trying to learn more about the forgejo oauth code. Feel free to join the [development room in Matrix](https://matrix.to/#/#forgejo-development:matrix.org) if you have any questions.

matrss commented

2025-08-29 11:03:19 +02:00

Contributor

@abueide Hey! I would love to have this feature for oauth authentication on our HPC systems, where outgoing ssh connections are blocked and manually handling API tokens is a bit annoying (and less secure than git-credential-oauth). Are you still planning to work on this at some point? Otherwise I might take a stab at it myself, whenever I'd get around to it.

Gusted commented

2025-08-29 22:48:04 +02:00

Owner

I think you're free to go ahead and implement this.

ccmtaylor referenced this issue from a pull request that will close it,

2025-12-09 00:26:19 +01:00

support OAuth2 device authorization for headless clients #10373

ccmtaylor commented

2025-12-09 00:30:20 +01:00

I gave this a go; you can find a WIP PR here: #10373.

I tested the functionality manually, and it works. You can find setup instructions in the PR description.

Unit/integration test coverage is only marginal, and I could use some help with the UI, since I'm not much of a web person. The UI also looks a bit broken because I haven't figured out how translations work yet.

Feedback would be much appreciated!

I gave this a go; you can find a WIP PR here: https://codeberg.org/forgejo/forgejo/pulls/10373. I tested the functionality manually, and it works. You can find setup instructions in the PR description. Unit/integration test coverage is only marginal, and I could use some help with the UI, since I'm not much of a web person. The UI also looks a bit broken because I haven't figured out how translations work yet. Feedback would be much appreciated!

❤️ 2

ccmtaylor commented

2025-12-10 21:16:05 +01:00

it keeps device grants separate from OAuth grants
device grant support is configurable per-application
doesn't support verification_uri_complete (i.e. to allow clients to use QR-codes / NFC)

I just noticed there's a similar PR for gitea here: https://github.com/go-gitea/gitea/pull/35379. Since gitea is MIT licensed, we could also adopt that. Some differences from my approach: * it keeps device grants separate from OAuth grants * device grant support is configurable per-application * doesn't support verification_uri_complete (i.e. to allow clients to use QR-codes / NFC)

👀 1

oliverpool added the

code/auth/faidp

label

2025-12-20 11:49:15 +01:00

matrss commented

2026-01-04 03:06:31 +01:00

Contributor

@ccmtaylor wrote in #4830 (comment):

I just noticed there's a similar PR for gitea here: https://github.com/go-gitea/gitea/pull/35379. Since gitea is MIT licensed, we could also adopt that. Some differences from my approach:

it keeps device grants separate from OAuth grants

device grant support is configurable per-application

doesn't support verification_uri_complete (i.e. to allow clients to use QR-codes / NFC)

I'm not very familiar with the related RFCs so take this with a grain of salt, but my intuition says:

The device authorization flow is merely an alternative way to authorize a client application. When the authorization is finished there is no difference between the permissions granted to a client application that used the device flow and those granted to one that used the regular flow. So I don't see a point in keeping two separate tables.
Along the same lines, I don't see a point in restricting the allowed authorization flow on a per-application basis. As long as there are no known weaknesses in the spec or implementation the user should be free to use what makes sense given their use-case. In case there is a weakness discovered in the device flow it might make sense to have a configuration option to disable it entirely.

Regarding verification_uri_complete, it would be very useful for my specific use-case: I am using git-credential-oauth on HPC systems via ssh. If Forgejo provides verification_uri_complete and if git-credential-oauth were to just print this full link, then I would just have to click the link to open it in my local browser. This would be almost as convenient as the regular oauth flow, which opens the link automatically.

All that to say: your approach seems preferable to me.

@ccmtaylor wrote in https://codeberg.org/forgejo/forgejo/issues/4830#issuecomment-8849853: > I just noticed there's a similar PR for gitea here: https://github.com/go-gitea/gitea/pull/35379. Since gitea is MIT licensed, we could also adopt that. Some differences from my approach: > > * it keeps device grants separate from OAuth grants > * device grant support is configurable per-application > * doesn't support verification_uri_complete (i.e. to allow clients to use QR-codes / NFC) I'm not very familiar with the related RFCs so take this with a grain of salt, but my intuition says: 1. The device authorization flow is merely an alternative way to authorize a client application. When the authorization is finished there is no difference between the permissions granted to a client application that used the device flow and those granted to one that used the regular flow. So I don't see a point in keeping two separate tables. 2. Along the same lines, I don't see a point in restricting the allowed authorization flow on a per-application basis. As long as there are no known weaknesses in the spec or implementation the user should be free to use what makes sense given their use-case. In case there is a weakness discovered in the device flow it might make sense to have a configuration option to disable it entirely. Regarding verification_uri_complete, it would be very useful for my specific use-case: I am using git-credential-oauth on HPC systems via ssh. If Forgejo provides verification_uri_complete and if git-credential-oauth were to just print this full link, then I would just have to click the link to open it in my local browser. This would be almost as convenient as the regular oauth flow, which opens the link automatically. All that to say: your approach seems preferable to me.

ccmtaylor referenced this issue

2026-01-15 22:07:19 +01:00

support OAuth2 device authorization for headless clients #10373

Gusted referenced this issue

2026-02-09 16:47:47 +01:00

support OAuth2 device authorization for headless clients #10373