Refactoring access token from sha1 to sha1+JWT #115
No reviewers
Labels
No Label
has/backport
has/pull
in progress
invalid
kind/breaking
kind/bug
kind/build
kind/deployment
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/proposal
kind/question
kind/refactor
kind/security
kind/testing
kind/translation
kind/ui
need/backport
priority/critical
priority/low
priority/maybe
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/go-sdk#115
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "beeonthego/beeonthego-jwt-server-integration"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Author: @beeonthego
AccessToken returned from API can include JWT as content, and sha1 hash of the content for backward compatibility. during transition period, the api can accept old and new sha1, and allow integrated apps to use JWT in the future.
Author: @beeonthego
@lafriks @lunny @tboerger @appleboy @bkcsoft could someone review the code and comment whether the proposed data structure is acceptable? Our main PR depends on the new struct in api client in the vendor folder, otherwise it will fail the dependency test.
The super user server token is optional. It just makes future app integration easier, without relying on basic auth. Single factor basic auth is the weakest point in the whole system, when user picked password is not strong enough.
Author: @tboerger
Why do we need jwt instead of simple tokens for api authentication?
Author: @beeonthego
That is a good question, and we have debated over this internally when redesigning the whole process. The primary purpose is to enhance security and to avoid storing token in the db.
Currently Gitea (and Drone) stores the simple token in DB, which is equivalent to passwords. Having access to the tokens means total access to the account. It is not a good practice to store them as plain texts.
In our new process, we store the plain text claims in db, and inject the signing key as environment variable. We can reconstruct the token with claims and signing key, and return to Drone(or other integrated apps) when users log in. However unauthorized access to the db (token hash and claims) won't be able to access the api.
The sha1 hash of the signed token is also stored in db for backward compatibility during transition period. The hash is fixed length, indexed to verify the key for extra precaution.
JWT can contain a bit extra info such as user name, expiry time, intended use etc. it can be used to grant partial access to some resources. Another benefit is that we can verify the token signature at api gateway on separate machines without db query. This decoupled design helps the application to scale.
This is designed to guard against escalated privileges as a result of unauthorized access to db. Not so long ago a major cloud provider had an incident of not removing data when the volume was provided to another user. This has happened before and may happen again in the future, as cleaning scripts fail sometimes. The signing key only lives in memory and thus reduces the risks. of course this strategy won't cover everything. it is a small step towards a business wise reasonable endeavour.
Author: @lunny
Please resolve the conflicts.
upstream changes need first if i understand correct ...
Pull request closed