# AuthKey

## AuthKey

AuthKey is similiar to a session in web 2.0. It's used to identify users and their authority of operation in TApps.

### Why not use username/password?

Almost all user activies happen in layer2 instead of layer1, but the user authentication happens in layer1 only. The only thing we can determine via user authentication is the user signature using a blockchain wallet (such as Metamask or Ledger). You may ask why we cannot use the traditional username/password as most web 2.0 applications typically use. The reasons are:

* We try to make all users annoymous by not connecting user\_id with any personal information, such as email/phone number.
* Saving passwords (even hashed) anywhere in layer2 may attract hackers.
* Many users will not set a strong password to protect themselves.
* Many users forget their passwords and we can hardly help them to get it back or reset it due to the annoymous nature of blockchain wallets.

Because of these issues, we would like to use the end user's blockchain signature as the solo way to identify them.

### Operation of Auth in AuthKey

The AuthKey includes the allowed operations list. User will get promoted in the UI before signing the authkey on what operations are allowed (allowance to spend by this TApp (max expense), Allowance to transfer, Withdraw etc.)

Tihis operation list is a JSON string that's signed using the user's blockchain private key. [hosting\_cml](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/hosting_cml.md) will not verify this signature, but the [provider](/z_glossary/provider.md) inside the [state machine](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/state_machine.md) will. Even if the [state\_machine\_actor](/z_glossary/state_machine_actor.md) was coded by the developer to allow transfering user's funds, the [provider](/z_glossary/provider.md) of the [state](/z_glossary/state.md) will double check to confirm if this operation is still allowed by the user. In this case, even if the developer is a bad actor that's trying to steal user's money, it will be blocked by the [state machine](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/state_machine.md) eventually.

In other words, the design of TEA Project allows for the worst-case assumption that a developer's trying to steal users' money but the AuthKey logic inside the [provider](/z_glossary/provider.md) of [state](/z_glossary/state.md) prevents this from happening.

### How does it work?

The TApp developer will set an AuthKey profile string (in JSON format) based what the end user's supposed to do after login. This profile should only include the necessary operations. If any more than the required operations are included it may cause the end user to reject signing the transaction and even report the TApp to the DAO.

When a user logs in to a TApp, this AuthKey profile string will be part of the to-be-signed string and shown in the wallet UI. The end users should review these allowed operations before signing.

The signing process is the same as using Metamask to sign an Ethereum transaction. The only difference is this signed string will not be sent to the blockchain, but to the [hosting\_cml](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/hosting_cml.md) instead.

Once signed, the user agrees that this TApp can do what's been allowed in this string. The signed string is sent to the [state machine](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/state_machine.md) and stored there temporarily with a nonce handle. This nonce handle is called **AuthKey**. This AuthKey is returned to the [hosting\_cml](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/hosting_cml.md) and the user's browser. Every time this user wants to run any [queries](/z_glossary/queries.md) or [commands](/z_glossary/commands.md) that require authorization, this AuthKey will be sent to the [hosting\_cml](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/hosting_cml.md) and eventually to the [state\_machine\_actor](/z_glossary/state_machine_actor.md). When the [state\_machine\_actor](/z_glossary/state_machine_actor.md) actually calls the [provider](/z_glossary/provider.md) of [state](/z_glossary/state.md), the AuthKey will be checked before it can actually be allowed to run. If there is any violation, an error will be thrown.

## AuthKey expiration

Like regular sessions in web 2.0, an AuthKey has an expiration time. If the user stops sending any activity for 30 minutes (this length of time is configurable), the AuthKey is expired. The end user has to re-login to create a new AuthKey to continue operations.

## AuthKey security

If a sniffer get this AuthKey, he can impersonate the user and cheat the system. So the security of AuthKey is very important. In [hosting\_cml](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/hosting_cml.md) and [state machine](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/state_machine.md), the AuthKey always stays inside the hardware [enclave](/z_glossary/enclave.md). During transportation between [enclaves](/z_glossary/enclave.md), TLS security is always applied. Between browser and the [hosting\_cml](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/hosting_cml.md), a special end-to-end encryption is applied to keep the AuthKey secure.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://dev.teaproject.org/z_glossary/authkey.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
