Define the scenarios on the Studio for the usage of authWithAPIKey call

[chrisli30]

request.setOwner(address) is added to the authWithAPIKey. Since this API key gives the request an admin rights, which could view any wallet address, is there a reason to bind one specific wallet address to it?

38b6d89#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80R72

Additionally, I don’t think the third parameter expired_at is needed either. If a developer get an API key from us, the key solely should pass auth and offer admin rights. So basically I’m suggesting,

authWithAPIKey(apiKey)
instead of
authWithAPIKey(walletAddress, apiKey, expiredAt)

[v9n]

we do need the address when auth with api key. otherwise how do we know who is the requester ?

Since this API key gives the request an admin rights, which could view any wallet address, is there a reason to bind one specific wallet address to it?

Yes, to know who to grant the request to.

authWithAPIKey(apiKey)
instead of
authWithAPIKey(walletAddress, apiKey, expiredAt)

I'm struggling to see that works. Can you elaborate how that will work in your vision?

---

I want to provide a background info for our auth flow because it's a 2 steps system.

1. A person can use either their own signature(derive from their wallet private key), or an API KEY to exchange for an AUTH TOKEN. This AUTH TOKEN is short life, bind to a single wallet address only. That's why it's important to pass the wallet over so we can generate the AUTH TOKEN for that wallet only.
2. For every subsequent request: creating wallet, manage task you use this AUTH TOKEN. You NEVER use the API KEY directly for creating tasks, management wallet.

Here, we only use the API key on step 1. We didn't use that API key in step 2.

[chrisli30]

Okay, I see where our gaps are. The API Key I mentioned is a tradtional API Key, that gives a developer to master operations of all users of one’s application. For example, currently the Studio leverages an API Key.

The implementation of it should be separated from the user signature generated AuthToken, due to the below reasons.

1. Developer’s API Key is a tier-1 authentication. Since it can master multiple EOA accounts, there’s no need to bind one wallet to it.
2. User signature is a tier-2 authentication. One user AuthKey can only master the operations of one EOA account.
3. User would never need an API Key and should always use the tier-2 method to acquire the authKey.

Right now the same code manages two different security settings, and my suggestion is that they should be speparated. Their permissions are different, so should the usage, in other words the parameters of authWithAPIKey().

[v9n]

Developer’s API Key is a tier-1 authentication. Since it can master multiple EOA accounts, there’s no need to bind one wallet to it.

no, we don't bind any wallet to an api key.

User signature is a tier-2 authentication. One user AuthKey can only master the operations of one EOA account.

yes, we're doing that

User would never need an API Key and should always use the tier-2 method to acquire the authKey.

Yes, we 're doing that too

Right now the same code manages two different security settings, and my suggestion is that they should be speparated.
Their permissions are different, so should the usage, in other words the parameters of authWithAPIKey().

I think what you're suggesting is we pass the API KEY on every request? Allow me to explain the current design.

The API Key and the Auth key are 2 different thing. They use in different context.

Every request to create wallet, and manage task require an Auth Key. That's the only way to authentication with us. The Auth Key is a JWT token so we don't need to store session anywhere.

There are 2 ways to generate this auth key.

1. As an end user, you're the owner of an EOA, and having private key, you can generate a signature to prove that you own that OEA and we will generate and return an AUTH KEY for you. Auth Key is JWT so we don't need to store or check our db when auth request comes in

2. As an internal app (like sutdio, and in the future third party app), you can use an API KEY, to generate AUTH KEY for any wallet(or wallet that grant you permission in the future).

The only thing an API KEY can do is generate an AUTH KEY. It cannot do anything else. We never bind any wallet to API KEY. The AUTH KEY is a JWT KEY and it does encapsulate who generate it (user signature or api key).

Without the AUTH KEY concept, every single time a user do something how would they authenticate their request? Notice as an end user, they don't have an API KEY. Well, their only choice is to sign some message to prove the ownership. Then they would need to generate it every single request: list task, view task. That's why I introduce the AUTH KEY concept. As an end-user, take your wallet private key, exchange for an AUTH KEY, with an expiration. Now send that AUTH KEY in every request.

Now, when sending data to server, the AUTH KEY already contains information about who are they, they don't need to specify that in the request payload.

When you send API KEY directly to every request, suddenly now in the request payload we need to specify it.

Therefore, I solve it nicely with the API KEY concept. Where this API KEY doesn't and cannot do anything. It can only use to exchange for an AUTH KEY for any wallet. Effectively allow an app to manipulate user data.

I'm open to change. Just want to make sure I understand what you want to achieve.

I would be easiser if you can share some sample code in the SDK that you think we should switch to? then I can update the server to match.

[chrisli30]

Let’s keep the design for now, and use an address for the owner of API key.

What we need is a list of scenarios on the Studio side from the API key.

• Display a user’s task after they connect a wallet, but not signed.

Currently we don’t have a feature to use on API key to display multiple user’s data.

Also for our telegram bot we need scope: write, but for a 3rd party develoeper, only scope: read on the API key.

This is related to #36 as well.