Roles

The protocol defines 4 roles:

1. Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
2. Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
3. Wallet: This is the cryptocurrency wallet.
4. Authentication server: The server issuing access tokens to the client after successfully authenticating the resource owner.

Protocol flowchart

+--------+                +--------+
|        |                |        |
|        <--sign request--|        |
| Wallet |                |        |
|        |                |        |
|        |---signature---->        |
+--------+                |        |                    +-------------+
                          | Client |----signature------->             |
                          |        |                    | Auth Server |
                          |        |                    |             |
                   +      |        <---access token-----|             |
                          |        |                    +-------------+
                          |        |
                          |        |                    +-------------+
                          |        |---access token----->             |
                          |        |                    |  Resource   |
                          |        |                    |   Server    |
                          |        <-protected resource-|             |
                          |        |                    +-------------+
                          |        |
                          +--------+

The abstract protocol flow illustrated above describes the interaction between the four roles and includes the following steps:

1. Client → Wallet (sign request): The client requests wallet to sign a nonce. The nonce is to be generated by the client.
2. Wallet → Client(signature): The wallet signs the nonce and returns the signature. It also piggybacks its public key (wallet address).
3. Client → Authentication server(signature): The client passes the signature, wallet address and the NFT information (viz. NFT contract address and the NFT token id) to the authentication server.
4. Authentication server → Client (access token): The authentication server verifies the signature using the wallet address. If the verification passes, it verifies if the NFT, for which the contract address and token id was passed, is owned by the wallet. If this verification passes, it issues an access token. If the verification fails at any step, it responds with an appropriate error to the client.
5. Client → Resource server(access token): The client uses the access token to request the protected resource from the resource server.
6. Resource server → Client (protected resource): The resource server verifies the access token and accordingly responds with error (if the access token is invalid or expired) or with the protected resource (if the access token is valid)

Protocol endpoints

The authentication utilizes one external server endpoint (HTTP resource): Token endpoint