# Democratizing Deep Learning Applications in Earth and Climate Sciences on the Web: EarthAlHub
## 2 Materials and Methods
### System Modules
#### 2.3.1 User Management Module  
EarthAIHub is designed as a community-driven platform; thus, authorization and authentication of users is an integral part of the system. To facilitate these, we used JSON Web Tokens (JWTs) [42], which is a proposed internet standard. A JWT is a signature of a user. In authentication, a JWT should be generated by an authority and returned to the user once they provide a set of credentials, such as a username and a password, successfully. Thus, instead of expecting a user to log in every time they make a request or  
Figure 3: Modules and their connections over different tasks on EarthAIHub. Figure 2: A sample configuration file. keep session information in the browser, a JWT can be used to authenticate and authorize a user. Based on this widely used methodology, the platform implements an authentication and authorization system that only expects a username and a password from the user. Furthermore, the User table in the database implements an administration functionality where users with an is_admin flag are able to carry out certain tasks such as approving and rejecting submitted models. All the fields that a User table in the database holds can be seen in Table 16 in the appendix. **User Creation:** User creation is carried out by filling out a registration form consisting of a username and two password fields. Once a user submits the registration form, the client side validates that both passwords are the same. The server side first checks if a user with the given username already exists. If the user does not exist, it creates a new user entry in the database, saving the password encrypted with SHA256. **User Login:** Login functionality on the client side is twofold: POSTing the entered credentials to the server side, and saving returned JWTs on the client side when login is successful. However, the server side handles a more crucial operation once it confirms that the given credentials are correct. The server-side component creates a pair of JWTs for the given user: an access token and a refresh token upon login. An access token is a short-lived JWT, typically for 15 min. It can be used to perform actions throughout the web application that need authorization. On the other hand, a refresh token is a relatively long-lived JWT, typically for 30 days, that can only be used to refresh the access token with a new one. Once these tokens are created, they are sent to the client side. Knowing that the login was successful, the client-side application saves these two tokens as cookies with expiration dates and prompts the user that the login was successful. From that moment on, whenever the client side needs to make a request that needs authentication, it POSTs the access token as a header along with other data to the server side. However, since the access token is short-lived, a new mechanism is needed to refresh the access token when it is about to expire or has expired already. This is ensured by a function that is run on the client side right before every request that needs to be authorized. To facilitate this, there is a specific route on the server side that checks if the used JWT is an access token and is still valid. If the current access token saved on the client side cannot pass this check, the client-side scripts then proceed to refresh the access token by requesting a token from the refreshing endpoint on the server side with the refresh token as a header in the request. If that endpoint rejects the provided refresh token, then it means either the provided refresh token is corrupt, or it has expired. In either of these cases, the client side receives an error message from the server side, deletes all JWTs from cookies, and redirects to login. How JWTs encrypt user information, validate them, and separate access tokens from refresh tokens will not be discussed here, as we believe these are beyond the scope of this study. We refer the reader to the JWT documentation [41] to better understand these concepts.