-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Minimal OpenID Connect implementation #14139
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
Conversation
Please run make fmt |
… and |
bdc9bb1
to
8f09365
Compare
Was there something in particular you had in mind? I ran this a lot of times before pushing, and even now I don't get any more corrections when running this.
I accidentally made some mistakes here in the "final cleanup" before pushing though...sorry for the noise. |
6110e62
to
a43926f
Compare
Codecov Report
@@ Coverage Diff @@
## master #14139 +/- ##
==========================================
- Coverage 42.01% 42.00% -0.01%
==========================================
Files 733 734 +1
Lines 78715 78770 +55
==========================================
+ Hits 33073 33090 +17
- Misses 40212 40243 +31
- Partials 5430 5437 +7
Continue to review full report at Codecov.
|
a43926f
to
5364143
Compare
5364143
to
92eb3b8
Compare
I think this PR will resolve #1310, perhaps I should have written that in the description box? (it seems I can't manually link issues to this PR) |
You can just amend the commit message and put a |
16f93e0
to
962e30f
Compare
This is "minimal" in the sense that only the Authorization Code Flow from OpenID Connect Core is implemented. No discovery, no configuration endpoint, and no user scope management. OpenID Connect is an extension to the (already implemented) OAuth 2.0 protocol, and essentially an `id_token` JWT is added to the access token endpoint response when using the Authorization Code Flow. I also added support for the "nonce" field since it is required to be used in the id_token if the client decides to include it in its initial request. In order to enable this extension an OAuth 2.0 scope containing "openid" is needed. Other OAuth 2.0 requests should not be impacted by this change. This minimal implementation is enough to enable single sign-on (SSO) for other sites, e.g. by using something like `mod_auth_openidc` to only allow access to a CI server if a user has logged into Gitea. Fixes: go-gitea#1310
962e30f
to
65dd5bf
Compare
@ojohnny now you only can wait until two of us had time to review, you can remind us by hitting the "update branch" button, but thats all |
@lafriks I'm afraid that this should be a feature since it implemented an OpenID Provider. |
This looks correct I just was looking for some way to check against a spec - but couldn't find the spec easily |
This is "minimal" in the sense that only the Authorization Code Flow
from OpenID Connect Core is implemented. No discovery, no configuration
endpoint, and no user scope management.
OpenID Connect is an extension to the (already implemented) OAuth 2.0
protocol, and essentially an
id_token
JWT is added to the access tokenendpoint response when using the Authorization Code Flow. I also added
support for the "nonce" field since it is required to be used in the
id_token if the client decides to include it in its initial request.
In order to enable this extension an OAuth 2.0 scope containing
"openid" is needed. Other OAuth 2.0 requests should not be impacted by
this change.
This minimal implementation is enough to enable single sign-on (SSO)
for other sites, e.g. by using something like
mod_auth_openidc
toonly allow access to a CI server if a user has logged into Gitea.
Fixes: #1310