Need more clarity on authorization

⚙️ Flow SDKs
1

While going through the flow transection process, i came across two ways to create ‘authorization’.

One way is very simple, use the fcl sdk.

        const authorization = fcl.currentUser().authorization;
        await fcl.send([
            fcl.transaction`
              transaction {
                prepare(acct: AuthAccount) {
                  log(acct)
                }
              }
            `,
            fcl.proposer(authorization),
            fcl.authorizations([authorization]),
            fcl.payer(authorization),
            fcl.limit(9999),
        ])

Other way, where we need to use address and private key, as below. copied from kitty-items

authorizeMinter = () => {
return async (account: any = {}) => {
  const user = await this.getAccount(this.minterFlowAddress);
  const key = user.keys[this.minterAccountIndex];
  let sequenceNum;
  if (account.role.proposer) {
    sequenceNum = key.sequenceNumber;
  }
  const signingFunction = async (data) => {
    return {
      addr: user.address,
      keyId: key.index,
      signature: this.signWithKey(this.minterPrivateKeyHex, data.message),
    };
  };
  return {
    ...account,
    addr: user.address,
    keyId: key.index,
    sequenceNum,
    signature: account.signature || null,
    signingFunction,
    resolve: null,
    roles: account.roles,
  };
};

};

now my doubts :

  1. what is difference in both?
  2. when to use what?
  3. will both the code run on frontend side, or we must use node server to run the other one (authorizeMinter)?
2

@gregsantos @JeffreyDoyle Can you help here?

3

the authorization function in your first example const authorization = fcl.currentUser().authorization is a function that implements the second one, but instead of signing the transaction directly using a known private key, it asynchronously sends what needs to be signed to the wallet (via instructions fcl received during authentication), the wallet then signs it and then sends back the signature.

We call this an authorization function. It has the signature authFn :: account -> account where account = { addr, keyId, signingFunction, roles } and signingFunction :: signable -> compositeSignature

fcl.currentUser().authorization more or less looks like this:

async function authorization(account = {}) {
  await forceAuthentication()
  const {address, keyId, requestSignatureFromWallet } = await getUserInfoWalletConfig()

  return {
    ...account,
    addr: address,
    keyId: keyId,
    signingFunction: requestSignatureFromWallet
  }
}

Where requestSignatureFromWallet triggers the iframe and all that which allows the user to approve the transaction.

The authorization function works in two steps, the first tells the transaction which address and keyId are going to be signing as well as how to get a signature for that address/keyId. The second step gets the signature using that who (address/keyId) and how (signingFunction) specified in the first step. These two steps need to happen because the data that is signed includes who needs to sign it and requesting a signature at the time of specifying who the signer is gets all messed up if more than one account needs to sign something.

TL;DR
The first example is simple because it hides the stuff happening in the other example.

Answers to your question:
1 - they are the same
2 - browser use fcl, node you will need to implement your own signing function, you shouldnt be able to sign transactions on behalf of your users from node, as currently that would require you to have their private keys and you shouldnt ever have that.
3 - if the minter account was an fcl compatible account (blocto?) it could mint things from the browser using the first one, other wise you will need a node based signing function and provide that node service your private key