-
Notifications
You must be signed in to change notification settings - Fork 53
Refactoring access token from sha1 to sha1+JWT #115
base: master
Are you sure you want to change the base?
Refactoring access token from sha1 to sha1+JWT #115
Conversation
AccessToken returned from API can include JWT as content, and sha1 hash of JWT content for backward compatibility. During transition period, the api can accept both old and new sha1, and JWT. This allows integrated app to adjust and move to JWT only in the future.
gitea/user_app.go
Outdated
@@ -40,6 +41,17 @@ func (c *Client) ListAccessTokens(user, pass string) ([]*AccessToken, error) { | |||
// swagger:parameters userCreateToken | |||
type CreateAccessTokenOption struct { | |||
Name string `json:"name" binding:"Required"` | |||
MatchOwner []string `json:"match_owner,omitempty"` | |||
MatchRepo []string `json:"match_repo,omitempty"` | |||
RegexMatchBranch []string `json:"regex_match_branch,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although regex is more powerful for ease of use I would prefer wildcard match:
https://golang.org/pkg/path/filepath/#Match
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks and agree. regex was the word came to my mind but actually I meant wildcard.
as a reminder to the matching implementation.
provide the option for admin user to generate tokens on behalf of an authenticated user. ListAccessTokens will continue to work with user name and password.
username is already in path variable.
go with convention :)
@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. |
Why do we need jwt instead of simple tokens for api authentication? |
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. |
Please resolve the conflicts. |
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.