Move the token API discussion into a common section discussing the
generation and listing of the tokens. Add a note on the display of
the sha1 during creation and listing.
Co-authored-by: Norwin <noerw@users.noreply.github.com>
* Added OpenAPI document link to usage
The OpenAPI document at /api/swagger.v1.json needs an obvious reference. Sadly, I am English monolingual, so someone else is going to have to do the other languages. In the mean time, this PR should help anyone looking for the file.
* Update docs/content/doc/developers/api-usage.en-us.md
Co-authored-by: a1012112796 <1012112796@qq.com>
Co-authored-by: techknowlogick <matti@mdranta.net>
Co-authored-by: a1012112796 <1012112796@qq.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
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: #1310
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Ikko Ashimine