Refactoring access token from sha1 to sha1+JWT #115

Closed
lunny wants to merge 6 commits from beeonthego/beeonthego-jwt-server-integration into main
Owner

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 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
Owner

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: @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
Owner

Author: @tboerger

Why do we need jwt instead of simple tokens for api authentication?

Author: @tboerger Why do we need jwt instead of simple tokens for api authentication?
Author
Owner

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: @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
Owner

Author: @lunny

Please resolve the conflicts.

Author: @lunny Please resolve the conflicts.
6543 added the
upstream/gitea
label 2020-01-29 22:49:38 +00:00
Owner

upstream changes need first if i understand correct ...

upstream changes need first if i understand correct ...
techknowlogick closed this pull request 2020-02-09 01:10:10 +00:00
techknowlogick deleted branch beeonthego/beeonthego-jwt-server-integra 2020-02-09 01:10:18 +00:00

Pull request closed

Sign in to join this conversation.
No description provided.