# OAuth Client Credentials in Azure AD explained for Web API developers

Client credentials is one of the OAuth 2.0 flows primarily designed for addressing server-to-server scenarios (e.g., server code in a web app invoking a web API). It also fits within the category of confidential flow, as the authentication credentials must be stored securely in a private location. Anyone that gains access to those credentials can negotiate an access token. 

The Resource Owner Password Flow (ROP) is another option for supporting a similar scenario. However, there is an important distinction between those two flows. ROP requires an additional username and password to impersonate the call on behalf of a user. It is often abused and used as a replacement for the authorization code flow when embedding a web browser in the client application is not feasible. It is no longer recommended as the client application code can access the user's password, and MFA can be skipped.

If you do not need to impersonate any user, client credentials is the way to go.

Client applications and Web APIs are represented in Azure AD as App Registrations. When you attach a set of credentials for authentication, like a pair of client id and secret or a client certificate to an App Registration, it becomes a Service Principal that can be used for the Client Credentials flow. 

For client certificates, the App Registration is only associated with the public key of the certificate. The client application issues a JWT signed with the private key, which also contains the Application ID for the App Registration, and passes that to the Authorization Server (Azure AD) for authentication. Azure AD extracts the Application ID for App Registration from the JWT, and validates the signature on the JWT with the public cert for that App Registration. If the signature verification passes, the client application is successfully authenticated.

For client id and secret, authentication is much simpler. Azure AD only compares the passed client id and secret against the ones attached to the App Registration.

While client applications and Web APIs are both App Registrations, the properties you configure for them are entirely different. We will go through the process of registering each to discuss the differences.

## Registering a Web API

A Web API requires a URI scope. That is a unique ID for identifying the API. It could be the URL where the API is hosted or any other URN. Keep in mind two things when assigning this scope to an API. 

- It should be unique across all the APIs in your Azure AD tenant and something you can easily recognize and associate with the API. The latter is important as the client application will use that ID as scope for requesting an Access Token for the Web API to Azure AD. 

- You can use something like a GUID, but it will be hard to correlate/associate to a Web API by simply looking at the code or script used for getting a new access token. 

You can associate Roles to an App Registration representing a Web API. Those roles are not OAuth scopes because they are not requested or consented to by the users. They are assigned by the owner of the Web API in Azure AD to one or more users or other app registrations. Suppose Azure AD determines the caller application or the user impersonating the call belongs to one of the available roles in the Web API. In that case, it will inject those in the access token (JWT) under the roles attribute.
You can define two types of Roles, Application Roles and User Roles, also known as Delegated Roles.  
Application Roles only work for the Client Credentials flow where Authorization is performed in the context of the caller application. The Delegated Roles are used for the rest of OAuth flows and OpenID Connect.

When you create a new role for your web API, you can set the type, which can be Application, User (Delegated Role), or both. Select Application if you are only planning to use it for client credentials. 

Many of the roles that Microsoft defined for the Azure APIs use the following naming convention, <resource>.<action>, which permits you to do <action> on <resource>. For instance, Users.ReadWrite on the Graph API allows any client application to read or update users with that API.

Roles are not global. As we said before, they are defined in the context of a Web API. Users.Write does not mean anything for Azure if it is not passed in the context of the Graph API. Azure AD uses the URI scope to identify the API, and then looks for the requested role in that API only.

Go to Azure Active Directory in your Azure Subscription to create a new App Registration for a Web API.

Go to the App Registrations option on the left menu for Azure Active Directory and click on "New Registration" 

![alt](https://photos.collectednotes.com/photos/4455/07b23e93-2811-4d8c-99e2-3d1269d6cc00?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20230103T140325Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20230103%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=9db5c6d40669108516d8a7b63f28b2dbf2f6d1a86e3ecbec18cb75928732974c)

Complete the name of your Web API and click on "Register".

![alt](https://photos.collectednotes.com/photos/4455/9c3a9983-607e-4a65-94ec-995dd3a79001?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20230103T140637Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20230103%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=55af9a06d5328985a9a8381309a2c54e0d7a20e00d9b453e98447094410822df)

Go to the "Expose an API" option on the left menu for this App Registration. Click on the "Set" link for the Application ID URI. That will set the URI Scope for the API. Configure the following value as URI "api://myapis/mywebapi".

![alt](https://photos.collectednotes.com/photos/4455/de63f4d7-607c-42e7-9cc6-b7d59ab203aa?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20230103T141042Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20230103%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=f0c018f748d66a8b7a694338a2d875d57aedfe8a06a1a161ef9c95fc94612488)

Go to the App roles option on the left menu for this App Registration. 

Click on "Create App Role". 

Fill out the following details:

Display Name: Admin Role

Allowed member types: Applications

Value: Admin

Description: Allows executing any operation on the web api

Click on "Create App Role". 

Fill out the following details:

Display Name: Read-Only Role

Allowed member types: Applications

Value: ReadOnly

Description: Allows read-only access on the web api

After following all these steps, you should have a new Web API that supports two roles, Admin and ReadOnly. 

## Registering a client application

A client application is another App Registration, but it will be used to negotiate an access token for consuming a Web API. For that reason, there are important things to define in a client application.

- The authentication credentials, which could be a pair of client id and secret, or a client certificate.

- The roles/permissions required on a Web API. This part if optional. If you don't define any authorization role for a Web API, any client application registered in the same Azure AD tenant will be available to get an access token to consume it. 

Go to Azure Active Directory in your Azure Subscription to create a new App Registration for the client application.

Go to the App Registrations option on the left menu for Azure Active Directory and click on "New Registration".

Complete the name of your client application and click on "Register".

Go to API permissions on the left menu for this App Registration. 

Click on the "Add a permission" link.

![alt](https://photos.collectednotes.com/photos/4455/cb2fa686-0df4-407e-b36a-d63173364ef6?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20230105T133057Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20230105%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=4c66bdd5e8ee2369a852a0011399eda336f47276d130cbbd82800cdd0481c4bc)

Go to the tab "APIs my organization uses" and look for the Web API previously registered.

The roles for the Web API will be listed, those are "Admin" and "ReadOnly". Select the role you want to grant to this client application.

![alt](https://photos.collectednotes.com/photos/4455/7385f041-463c-4d83-a34c-25c3f3d02b4d?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20230105T133110Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20230105%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=f48493711bafd1665e2901a25f1da219a702d3d82af4e61428b797ea9388c9b1)

Application Roles assigned to an App Registration are not automatically granted. The administrator for the Azure AD tenant must approve them first. That can be done by clicking on the option "Grant Admin consent". This step is very important as Azure AD won't inject any role into the access token if the Admin consent has not been granted. 

Go to "Certificates & Secrets" option on the left menu for this App Registration. 

Click on "New client secret". Enter a description to identify the secret and an expiration.

![alt](https://photos.collectednotes.com/photos/4455/78511f5e-9aa7-491b-a676-bff4075aa9fe?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20230105T133125Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20230105%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=11c9b3a40b83bc365113b4ec952be9d850f62a9641d5b2f201938d6f5de88869)

Take note of the "Value" for the new secret, as you won't be able to retrieve it next time. "Value" will be the client's secret for authentication. The client id is the App ID associated with the App Registration. Make sure to distinguish with Secret ID, which is not really used at all.

##Get an access token from Azure AD

Getting a new fresh access token or JWT from Azure AD with client credentials requires an HTTP POST with the following details,

```
URL: https://login.microsoftonline.com/{tenant}//oauth2/v2.0/token
Content-Type:  application/x-www-form-urlencoded
Body: 

client_id={client id}
&scope={web api uri scope}/.default
&client_secret={client secret}
&grant_type=client_credentials
```

**Tenant**: It's the tenant ID where the App Registration for the Web API and Client were created. 

**Client Id**: It's the App Id assigned to the App Registration created for the client.

**Scope**: It's the Web API URI scope that was assigned when the App Registration for the Web API was created. Azure AD uses an awkward convention not documented anywhere for the scope. When you use client credentials, "/.default" must be appended to the URI scope. No other value is allowed. This scope is used by Azure AD to determine which API the client application wants to consume and generate an access token for it. This will drive the generation of the JWT and how some of its attributes are set. For instance, the audience or AUD attribute will be the set with the App ID for the Web API, and roles attribute with all the roles assigned to the client in that given API. For our example, the complete value would be api://myapis/MyWebAPI/.default
**Client Secret**: It's the secret assigned to the App Registration for the client.

##Anatomy of a JWT (Access Token)

A JWT returned by Azure AD looks as follow.

```
{
  "aud": "api://myapis/MyWebAPI",
  "iss": "https://sts.windows.net/f6aba1d9-da41-4ea3-8f30-4970725586b9/",
  "iat": 1672924530,
  "nbf": 1672924530,
  "exp": 1672928430,
  "aio": "E2ZgYHD9N/XE5ot5He2iV1Z1VfAyAAA=",
  "appid": "55b2a7ec-73f3-45c2-af08-21ecc33dc40e",
  "appidacr": "1",
  "idp": "https://sts.windows.net/f6aba1d9-da41-4ea3-8f30-4970725586b9/",
  "oid": "1f3086f6-9164-45f2-b479-a93f64d1006a",
  "rh": "0.AX0A2aGr9kHao06PMElwclWGqGL1t9EZOxJMkZf3CB4gW3ucAAA.",
  "roles": [
    "Admin"
  ],
  "sub": "1f3086f6-9164-45f2-b479-a93f64d1007a",
  "tid": "f6aba1d9-da41-4ea3-8f30-4970725586a8",
  "uti": "G-1ZiIhWbkKJdvkZfawxAA",
  "ver": "1.0"
}
```

**aud**: The audience for the access token. This is used by the Web API to validate that the token was actually issued for it. 

**iss**: The issuer ID. This is an unique identifier for the Azure AD tenant.

**sub**: The client ID

**roles**: The roles assigned to the client on the Web API.

 

  


  


Client credentials is one of the OAuth 2.0 flows primarily designed for ad...

OAuth Client Credentials in Azure AD explained for Web API developers

# NFTs in Ethereum explained

NFT or Non-Fungible-Token is a relatively new concept that is hard to grasp for many.
A token in the scope of a Blockchain represents proof of ownership in a digital world, which means you can use it as evidence to prove you own something. There is a subtle difference between ownership and proof of ownership. You could own a car, but you might need an invoice or title to prove it is yours. A token represents the latter. You demonstrate a token is yours by using public and private key cryptography. The token is associated with an address that can only be computed with a private key you own.
A token was initially used to represent value in the native currency of a Blockchain or an equivalent fiat currency such as US Dollars. All the issue tokens were worth the same value. If you have one token, you could change with another token without making any difference or losing value.

NFTs were introduced to represent things with a unique value other than currency. As each NFT is unique, they have different intrinsic values as well. You can not simply change an NFT for another NFT anymore. They could represent ownership on digital assets such as images, subscriptions, game rewards, etc.

## NFTs in Ethrereum

NFTs are implemented in Ethrereum with Smart Contracts. It is worth mentioning that a Smart Contract is not an NFT but a source or factory for them.

The contracts in this scenario control how the NFTs are issued and assigned in the Blockchain. The following image shows how NFTs are grouped and stored in the Blockchain under their parent contract.

![alt](https://photos.collectednotes.com/photos/4455/a1963833-eda6-4393-96e5-710a29610405)

In that sense, they can not directly be accessed or located by an address in the Blockchain. The access is always controlled by a contract. NFTs are not a built-in construct in the Blockchain either, so anyone could implement the Smart Contract to manage them in any way. To prevent the latter from happening, different community members in Ethereum defined a primary interface with a few methods that any Smart Contract should adhere to be considered an NFT factory. That interface became the facto standard known as ERC-721. 

```solidity
pragma solidity ^0.4.20;

/// @title ERC-721 Non-Fungible Token Standard
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x80ac58cd.
interface ERC721 /* is ERC165 */ {
    /// @dev This emits when ownership of any NFT changes by any mechanism.
    ///  This event emits when NFTs are created (`from` == 0) and destroyed
    ///  (`to` == 0). Exception: during contract creation, any number of NFTs
    ///  may be created and assigned without emitting Transfer. At the time of
    ///  any transfer, the approved address for that NFT (if any) is reset to none.
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

    /// @dev This emits when the approved address for an NFT is changed or
    ///  reaffirmed. The zero address indicates there is no approved address.
    ///  When a Transfer event emits, this also indicates that the approved
    ///  address for that NFT (if any) is reset to none.
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

    /// @dev This emits when an operator is enabled or disabled for an owner.
    ///  The operator can manage all NFTs of the owner.
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /// @notice Count all NFTs assigned to an owner
    /// @dev NFTs assigned to the zero address are considered invalid, and this
    ///  function throws for queries about the zero address.
    /// @param _owner An address for whom to query the balance
    /// @return The number of NFTs owned by `_owner`, possibly zero
    function balanceOf(address _owner) external view returns (uint256);

    /// @notice Find the owner of an NFT
    /// @dev NFTs assigned to zero address are considered invalid, and queries
    ///  about them do throw.
    /// @param _tokenId The identifier for an NFT
    /// @return The address of the owner of the NFT
    function ownerOf(uint256 _tokenId) external view returns (address);

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT. When transfer is complete, this function
    ///  checks if `_to` is a smart contract (code size > 0). If so, it calls
    ///  `onERC721Received` on `_to` and throws if the return value is not
    ///  `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    /// @param data Additional data with no specified format, sent in call to `_to`
    function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;

    /// @notice Transfers the ownership of an NFT from one address to another address
    /// @dev This works identically to the other function with an extra data parameter,
    ///  except this function just sets data to "".
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
    ///  THEY MAY BE PERMANENTLY LOST
    /// @dev Throws unless `msg.sender` is the current owner, an authorized
    ///  operator, or the approved address for this NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Change or reaffirm the approved address for an NFT
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless `msg.sender` is the current NFT owner, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved NFT controller
    /// @param _tokenId The NFT to approve
    function approve(address _approved, uint256 _tokenId) external payable;

    /// @notice Enable or disable approval for a third party ("operator") to manage
    ///  all of `msg.sender`'s assets
    /// @dev Emits the ApprovalForAll event. The contract MUST allow
    ///  multiple operators per owner.
    /// @param _operator Address to add to the set of authorized operators
    /// @param _approved True if the operator is approved, false to revoke approval
    function setApprovalForAll(address _operator, bool _approved) external;

    /// @notice Get the approved address for a single NFT
    /// @dev Throws if `_tokenId` is not a valid NFT.
    /// @param _tokenId The NFT to find the approved address for
    /// @return The approved address for this NFT, or the zero address if there is none
    function getApproved(uint256 _tokenId) external view returns (address);

    /// @notice Query if an address is an authorized operator for another address
    /// @param _owner The address that owns the NFTs
    /// @param _operator The address that acts on behalf of the owner
    /// @return True if `_operator` is an approved operator for `_owner`, false otherwise
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}
```

>> Interfaces don't exist as a primary construct in the Ethereum Virtual Machine (EVM). They are supported in Solidity, but they don't correlate to anything once they are deployed. You can assume a Smart Contract follows a convention for the methods it provides.

Since a Smart Contract becomes the source for NFTs, it also makes a lot of sense for grouping collections like image collectibles.

>> NFTs are unique IDs mapped to an address (the owner) and stored in a Smart Contract.

Storage space in the Blockchain is expensive. As long as you store basic data about your NFTs in the storage, you should be good. How about images? That is a different story. Although it would make sense to store the whole blob of bytes for an image in the Blockchain, that would be extremely expensive and hard to manage in the long run. For that reason, the community found a different way to address that scenario. It is called NFT metadata. It is a JSON file that describes additional data about your NFT that you wouldn't store in the Blockchain. That metadata file contains, for example, an URL to the location of the image blob. This metadata file could be stored anywhere, but many prefer it in decentralized storage like IPFS. The Smart Contract ends up holding a reference to the location of this metadata in the Blockchain.

>> The chicken and egg dilemma. My NFT in the Blockchain assures data integrity. Once it is saved in the Blockchain, it can be changed. However, the same thing can not be ensured for the metadata file is pointing to. There are solutions to this problem. Store the metadata as text in the same storage as the Smart Contract, or store a checksum created from the data in the metadata file. 

## Implementing an ERC-721 contract
OpenZeppelin already provides a base contract that can be used as a starting point for any implementation that sticks to the ERC-721 standard.

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.2;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract TikenToken is ERC721, Ownable {
    using Counters for Counters.Counter; 
    
    Counters.Counter private _tokenIds;

    event TokenEmitted(string indexed symbol, address _sender, uint256 _id);

    constructor() ERC721("My NFT", "MYNFT") {
    }
    
    function createToken(string memory _tokenURI, address to) public onlyOwner returns (uint) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(to, newItemId);

        emit TokenEmitted(symbol(), to, newItemId);

        return newItemId;
    }
}
```

The code above shows a straightforward implementation of an ERC721 contract. 
It generates a new identifier for the NFT and calls the internal `_mint` method for associating the sender address with this new token (internally stored in a mapping).
This implementation does not offer any metadata for the NFTs. If you also want to store the URL for the metadata associated with the generated NFT, you must implement the `ERC721URIStorage` interface. 

```solidity
function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }
    
    function createToken(string memory _tokenURI) public onlyOwner returns (uint) {
        _tokenIds.increment();
        uint256 newItemId = _tokenIds.current();

        _mint(msg.sender, newItemId);
        _setTokenURI(newItemId, _tokenURI);

        emit TokenEmitted(symbol(), msg.sender, newItemId);

        return newItemId;
    }
```
These changes include a new method, `tokenURI` that returns the metadata URL associated with the token and a new line `_setTokenURI` in the `createToken` method for persisting the URL in the contract storage.

Finally, if you also want to support the ability to destroy or burn issued NTFs, you can also implement the interface `ERC721Burnable`

```solidity
function _burn(uint256 tokenId) internal override(ERC721, ERC721URIStorage) {
        super._burn(tokenId);
}
```
The method assigns the token to an address that is no longer accessible.



NFT or Non-Fungible-Token is a relatively new concept that is hard to grasp for many.
A token in the scope of a Block...

NFTs in Ethereum explained

# Implementing a basic ETH Pool - Exactly Finance's challenge explained

I am still in the process of learning Solidity and Smart contract development, and there is no better way to learn than building new stuff on it. Yesterday, I came across a code challenge from Exactly to build a basic pool in Ethereum. I thought it was going to be a great exercise to put some ideas into practice, so I decide to ahead and do it. What I am going to show here is a summary of all the design decisions and how I ended up implementing that solution.

#The Challenge

You can find the full description of the challenge here. In short, it requires implementing a pool where one or more participants can deposit funds. There is also a team that owns the pool and can contribute to it with rewards. Those rewards are distributed across all the participants in the pool according to their % of the stake. For example, if Participant A deposits 100 tokens and B 300 tokens, A owns 25% and B 75%. When A or B withdraws the funds from the pool, they should get their funds and also the corresponding % of the rewards sent to the pool until that point in time. Once a participant has left the pool, it won't be able to claim rewards in that pool anymore. Time is not mentioned anywhere in the description, so we won't consider it as a variable for the implementation.

#The implementation

The first thing is to define the Smart Contract structure. For this implementation, we will require at least three methods, 

* Deposit: for making deposits in the pool
* Withdraw: for withdraw funds from the pool
* Deposit Rewards: for teams members to distribute rewards through the members in the pool.

```
contract ETHPool {
  receive() external payable {}
  function depositRewards() public payable {}
  function withdraw() public {}
}
``` 

We could implement deposits in two ways, a traditional method or a receive method (previously known as the fallback method). I decided to use the latter to receive funds directly with a regular transaction without a data payload. Some wallets or exchanges don't support data payload.

##The Receive method

```
uint256 public total;
  
address[] public users;
      
struct DepositValue {
  uint256 value;
  bool hasValue;
}

mapping(address => DepositValue) public deposits;

receive() external payable {
                
   if(!deposits[msg.sender].hasValue) // only pushes new users
      users.push(msg.sender);

    deposits[msg.sender].value += msg.value;
    deposits[msg.sender].hasValue = true;

    total += msg.value;
}
```

The deposit implementation uses two data structures, a mapping for storing the funds associated with a user (deposits), and a list for tracking all the users in the pool (users). 
In the way the EVM works, there is no way to determine if an entry exists in a mapping, so we can not rely on the mapping to determine if the user is part of the list of users. I did not want to go through all the elements in the list either; that could be expensive for a long list. I decided to use a known workaround with a struct that contains a flag to determine if the entry was defined or not. 
Once a user makes a deposit, I store the funds in the mapping and add the user to the list if it was not added previously. 
Finally, I increase the total value in the pool. I decided to use a variable to store the contract's total and not use the balance. The latter is prone to [attacks](https://consensys.github.io/smart-contract-best-practices/known_attacks/#forcibly-sending-ether-to-a-contract)

##The DepositRewards method

```
function depositRewards() public payable  {
  require(total > 0); // No rewards to distribute if the pool is empty.

  for (uint i = 0; i < users.length; i++){
    address user = users[i];

    uint rewards = ((deposits[user].value * msg.value) / total);

    deposits[user].value += rewards;
   }
}
```

The challenge description does not mention time anywhere as a variable. It only describes the rewards are paid weekly. That implies that anyone with funds in the pool can receive rewards. It does not matter how long the funds were there. 
My implementation goes through all the users in the list and distributes the received rewards according to the % of the stake on the pool. 
I had to consider two things when implementing this method. 

1. If the pool is empty, so the total equals 0, there is no need to distribute any rewards. We want to rollback the transaction if that happens. Otherwise, the funds for the rewards will be lost.
2.  The EVM does not support decimals or float numbers, so you have to be careful when doing divisions. The initial formula I used was this one (user deposits / total) * rewards. However, that produced a result equal to 0 most of the time, as the user deposits were less than the total.

##The Withdraw method

```
function withdraw() public {
  uint256 deposit = deposits[msg.sender].value;
        
  require(deposit > 0, "You don't have anything left to withdraw");

  deposits[msg.sender].value = 0;

  (bool success, ) = msg.sender.call{value:deposit}("");
  
  require(success, "Transfer failed");
}
```

It checks the user's funds in the pool and transfers those. If the user does not have anything in the pool, the transaction is reverted. It also sets the deposits in the pool to zero before making the transfer to avoid reentrancy attacks. Once the transfer is made, it checks for the results and reverts the transaction if the call failed (our change in the deposits mapping is reverted as well).  
There is no need to use a reentrancy guard, as setting the deposit to 0 is making the same effect.   

##Managing the Team Members

The challenge description is clear about who can deposit rewards in the pool. That's the team members. We need to add support in our contract for adding members. A simple way is to pass a list of addresses in the constructor, but that's not flexible. Once the contract is deployed, the list of members can not be changed anymore. I decided to use the OpenZeppelin Access Control contract, which provides support for roles. 

```
import "@openzeppelin/contracts/access/AccessControl.sol";

contract ETHPool is AccessControl {
  constructor() {
    _setupRole(DEFAULT_ADMIN_ROLE, msg.sender);
    _setupRole(TEAM_MEMBER_ROLE, msg.sender);
  }
}

function addTeamMember(address account) public {
  grantRole(TEAM_MEMBER_ROLE, account);
}

function removeTeamMember(address account) public {
  revokeRole(TEAM_MEMBER_ROLE, account);
}
```

We assign the admin role and team member role to the Smart Contract's owner as a part of the constructor execution. The admin is the one that can assign users to the other roles.  I also added two methods to grant or revoke the team member role to/from a user.

Finally, the depositRewards method was modified to check for that role.

```
function depositRewards() public payable onlyRole(TEAM_MEMBER_ROLE) {
```

##Adding events

Events are nice to have features in Smart Contracts. They allow reporting information in the Blockchain transaction log that can not be inferred directly from a transaction. They can also be indexed and used by Dapps. 

```
event Deposit(address indexed _address, uint256 _value);
event Withdraw(address indexed _address, uint256 _value);
```

I added two events for reporting when a deposit or a withdraw was made. 
Those are called in the respective methods.

```
receive() external payable {
   ....
   emit Deposit(msg.sender, msg.value);
}

function withdraw() public {
  ...
  emit Withdraw(msg.sender, deposit);
}
``` 

##The complete implementation

You can find the complete source code in my [Github repository](https://github.com/pcibraro/challenge).

Implementing a basic ETH Pool - Exactly Finance's challenge explained

I am still in the process of learning Solidity and Smart contract developm...

Implementing a basic ETH Pool - Exactly Finance's challenge explained

# Chainlink Keepers - An alarm clock for your Smart Contracts

![alt](https://photos.collectednotes.com/photos/4455/63a34838-18c5-4896-9d52-9e36ec79a8a9)

Smart Contracts work in reactive mode. Once deployed in the Blockchain, they go to a hibernation state until some work needs to be done. When the work is completed, they go to bed again. They basically react to transactions by executing code.

On the contrary, Smart Contracts in proactive mode, which don't really exist in reality but can be emulated, watch for different conditions to wake up themselves and do their job without intervention. For example, a contract that runs automatically when it detects a price fluctuation or when a given date or time is reached.

These contracts require the intervention of an external agent or worker that is constantly pinging the contract to verify whether one of the conditions to run was met. Those conditions should be checked in one or more view methods to avoid paying gas to the network. That means they can be resolved locally without submitting transactions.

Running an agent or worker now means you require additional off-chain infrastructure, which is centralized. 

What if you can also leverage some of the existing decentralized network of oracles (DONs) from Chainlink to run those agents. Enter in the scene the Chainlink Keepers.

##Chainlink Keepers

Keepers is a feature recently added in Chainlink for hosting jobs that allow running Smart Contracts proactively. It uses DONs to run the jobs in a decentralized manner. 
Jobs are called Upkeeps, and the Smart Contracts must implement an interface with the following methods.

```
function checkUpkeep(
    bytes calldata checkData
  )
    external
    returns (
        bool upkeepNeeded,
        bytes memory performData
);

function performUpkeep(
    bytes calldata performData
) external;
```

`checkUpKeep` is the method called periodically by the jobs to check if some works need to be done. *It's the alarm clock for your contract*. It receives a parameter checkData, which could be helpful to check for the conditions in the method implementation. That data is a fixed value that you configure as part of the job. It must be implemented as a view to avoiding paying gas on each call. 
It returns two values, upKeepNeeded, which specifies if an action must be performed, and data to be passed to execute that action.

`performUpKeep` is the method where the Smart Contract does the work. It's called if upKeepNeeded returned a value equal to true.

Chainlink also offers an application where you can configure the jobs. As part of the configuration of the job, you must provide the following data.

* An email address
* Name of the job (unkeep)
* Address of the deployed contract
* Admin Address. This is the address of an owner that can withdraw funds associated to the contract.
* Gas Limit. This gas limit is for executing the performUnKeep method.
* Check Data, which is passed to the checkUpkeep method. This is an array of bytes (hex), which could result from using abi.encode.   

>> This feature is still in beta and the registration must be done manually in the [Keepers app] (https://keepers.chain.link/). Not support for automation APIs for the moment

##Anatomy of a Keeper contract

Let's say that you want to implement a Betting contract for a game with two participants. You would like to select a winner and distribute the gains after the game finishes.  

```
//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

interface KeeperCompatibleInterface {
    function checkUpkeep(bytes calldata checkData) external returns (bool upkeepNeeded, bytes memory performData);
    function performUpkeep(bytes calldata performData) external;
}

contract Betting is KeeperCompatibleInterface{
   
   uint public matchTimestamp;

    constructor(uint _matchTimestamp) {
      matchTimestamp = _matchTimestamp;
    }

    function checkUpkeep(bytes calldata checkData)  external view override returns (bool upkeepNeeded, bytes memory performData) {
         upkeepNeeded = (block.timestamp > matchTimestamp);
    }

    function performUpkeep(bytes calldata performData) external override {
        //calls an oracle to retrieve the result of the match
      
    }
}
```
The contract is set with a time lock through a timestamp received in the constructor. We can assume this represents the date and time after the game finishes, and we know who the winner is.

```
 uint public matchTimestamp;

    constructor(uint _matchTimestamp) {
      matchTimestamp = _matchTimestamp;
    }
```

The `checkUpkeep` method compares the current block timestamp with the timestamp assigned to the contract and returns a value indicating if the condition is satisfied or not.  

```
function checkUpkeep(bytes calldata checkData)  external view override returns (bool upkeepNeeded, bytes memory performData) {
         upkeepNeeded = (block.timestamp > matchTimestamp);
    }
```

Finally, the performUpkeep emulates a call to an Oracle in Chainlink that might hit an API to return the game's result.

```
function performUpkeep(bytes calldata performData) external override {
        //calls an oracle to retrieve the result of the match
      
}
```


alt

Smart Contracts work in reactive mode. Once deployed in the Blockchain, they go...

Chainlink Keepers - An alarm clock for your Smart Contracts

# The Web3 ecosystem for Ethereum

Web3 is an umbrella term for a new wave of applications that rely on decentralized technologies and the Blockchain. 
Since the inception of Ethereum, which brought the idea of executing code in the Blockchain, many new projects have emerged in this space to help developers implement decentralized applications.
The image above shows some of the most notable projects that you can start using today.

![alt](https://photos.collectednotes.com/photos/4455/b5d775c8-81c2-4253-801b-cb7036d15ec2)

Let's give a short overview of the purpose for each one.

##IPFS
"Interplanetary file system" (or IPFS) is a protocol and peer-to-peer network for storing and sharing files. As with any peer-to-peer network, there is no central server, and different nodes in the network replicate copies of the files. 
It would be equivalent to Bittorrent but with a different feature set, and it's what most developers in the Web3 space use today for hosting DApps, written as Single Page Applications, or store and share files. 
IPFS is also used to store assets related to the NFTs. 
Once you publish content in one of the IPFS nodes, it gets associated with an identifier that could use to locate it. 

Another critical aspect of IPFS if you are planning to host your DApp on it is content pinning. To ensure your files are retained in the network, you need to rely on a pinning service.  Infura, for example, offers a free plan for a limited space. 

##The Graph
The Graph project implements a protocol for indexing and querying data available in the Eth Transaction Log and IPFS.
It supports the idea of subgraphs, which allow developers to tailor the data to be indexed based on their needs. 
Those subgraphs are published through nodes in the network, and they can be queried from DApps. 

If your DApp has immediate needs to query data available in the transaction log (e.g., transactions or events), or data pushed in IPFS, you should start by looking into this project first.

##Chainlink
Chainlink is a project whose aim is to provide all the infrastructure and plumbing for running a network of Oracles (DONs) that integrate with existing Blockchain networks (Ethereum and others). It's not a Blockchain, but it offers the infrastructure to run heterogeneous networks with oracle nodes that act as intermediaries between Smart Contracts and applications running outside.
The value proposition or business value in Chainlink is to offer a mechanism to sell data to apps running in the Blockchain. If you have an API that provides data that might be useful in the Blockchain, you can publish it through a Chainlink's adapter in one or more nodes and get paid for every request made to it. The unit of payments is a LINK token, which is a standard ERC-677 token.
You can run one or more nodes or ask any existing node operators (service providers that run nodes in their infrastructure) to run the adapter for you.
In that sense, Chainlink represents a collection of decentralized oracle networks (DONs) with nodes hosting different adapters or connections with external applications.
One of the critical aspects of implementing autonomous apps that run in a Blockchain is that they can not rely on a single data source to make decisions. If the data source becomes unavailable or starts providing inaccurate information, it suddenly becomes a big mess.
Chainlink tries to address that issue by aggregating data from multiple sources and making it available through various nodes (horizontal scaling). If one node becomes unresponsive, the other nodes can take that work. The same thing with the data sources is that if one starts providing invalid data, they can still correct it by using other sources.

If you are building Smart Contracts that require interaction with the external world, this is the project to look into. 

##Ceramic and IDX
Ceramic and IDX are two relatively new projects backed by the same company, which address different scenarios.

Ceramic provides a mechanism for supporting data streams on top of IPFS. This project might be a good fit if you need to support scenarios like messaging in your DApp.

On the other hand, IDX is about user identity and authentication. It tries to provide an identity layer that any DApp could use to uniquely identify users in a decentralized manner. If you want your DApp users to be authenticated with ETH private keys and have a decentralized profile for them, this is the project.
 
##Polkadot
Polkadot is a project that provides interoperability between ETH and other  Blockchains. The idea behind Polkadot is that many of the different available Blockchain today have different purposes, there is any Blockchain that could do everything, and they need to interoperate somehow.  The connection between those Blockchain networks is made through bridges, which this project is going to provide.

A bridge is an intermediary for moving assets or data from one Blockchain to another. As the Blockchains use different protocols, rules, and governance models, the bridge provides various interoperable mechanisms on both sides. 

##Polygon
Polygon is a layer 2 project for Ethereum. It's well known that Ethereum suffers from scalability issues. It can only process 17 transactions per second, and the gas fees can be very high sometimes. 
Polygon runs on top of the Ethereum network and provides better transaction throughput and lower gas fees. It works as a secondary network with a bridge that allows moving assets (tokens) from one network and another. You could leverage Polygon to move load from the main Ethereum network into this L2 Blockchain and provide better response times and cheap gas fees to your users.

Web3 is an umbrella term for a new wave of applications that rely on decentralized technologies and the Blockcha...

The Web3 ecosystem for Ethereum

# Using Merkle Trees for Bulk transfers in Ethereum

Merkle Trees have become more popular than ever in the last decade for their heavy use in the crypto world.  Most Blockchain implementations rely on this data structure for validating transactions as part of the consensus protocols. 

What is a Merkle tree exactly? It's a data structure usually represented by a binary tree where each parent node contains a combination of hashes from their children.

The top of the tree is called root hash or Merkle root, and it is obtained from the process of re-hashing the concatenation of the child nodes starting from the last layer up to the top.
 
![alt](https://photos.collectednotes.com/photos/4455/cb3488a2-8faa-4f03-881a-d2fab843d576)

If the hash in one of the nodes is changed, the resulting tree and Merkle Root are also changed. This is an essential factor for one of the scenarios we will discuss in this article, bulk transfers. 

# The use of Merkle Trees for Bulk Transfers

 We all know that executing an operation like a transfer in a Smart Contract cost money (or Ether in technical terms), which is paid as gas to the validation nodes in the network. Now imagine that you have to make thousands of transfers; that's a lot of money giving the high prices of the gas in the ETH mainnet. 

This kind of scenario is fairly common for NFT airdrops, or in the betting industry. Merkle trees become handy for inverting roles in these particular scenarios. What if we make all the possible recipients claim their tokens instead of making a transfer to them. In that way, our solution would scale better as they will be responsible for paying the gas to claim the tokens. 

Let's now describe in detail how this solution works in practical terms. 
If we know all the addresses in advance, we can use a Merkle tree and compute a unique Merkle root. We can later distribute a proof representing one of the tree's nodes to each of these addresses.  

They can use the proof to claim the tokens. The Merkle root in our possession can validate the proof and make sure it belongs to the same tree. If the validation succeeds, we can assume the presented proof was ok, and we can issue the tokens.

This article will show you how to implement this with Solidity for a Betting scenario.

# Anatomy of the Betting Smart Contract

The implementation of our Smart Contract uses the OpenZeppelin Contract Library and MerkleProof utility. It's a contract for betting on a match with two teams, team one and team two.

This is how the contract looks like

```
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "hardhat/console.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import {MerkleProof} from "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";

contract Betting is Ownable {
  event GainsClaimed(address indexed _address, uint256 _value);
  
  using MerkleProof for bytes32[];

  uint256 public totalBetOne;
  uint256 public totalBetTwo;

  uint256 public minimumBet;

  address[] public playersBetOne;
  address[] public playersBetTwo;
      
  mapping(address => uint256) public players;
  mapping(address => uint256) public claimed;
  
  bytes32 merkleRoot;
  uint8 winner;
  
  constructor() Ownable() {
    // minimum bet is 1 gwei
    minimumBet = 1000000000;
  }

  function setMerkleRoot(bytes32 root, uint8 team) onlyOwner public 
  {
    merkleRoot = root;
    winner = team;
  }

  function checkPlayer(address player) public view returns(bool){
    return !(players[player] == 0);
  }

  function getTotalBetOne() public view returns(uint256){
    return totalBetOne;
   }
   
  function getTotalBetTwo() public view returns(uint256){
    return totalBetTwo;
  }

  function getPlayersBetOne() public view returns(address[] memory) {
    return playersBetOne;
  }

  function getPlayersBetTwo() public view returns(address[] memory) {
    return playersBetTwo;
  }

  function bet(uint8 team) public payable {
    require(team == 1 || team == 2, "Invalid team");

    require(!checkPlayer(msg.sender), "You bet on a game already");
    
    require(msg.value >= minimumBet, "Minimum bet is 1 gwei");
    
    require(merkleRoot == 0, "Bets are closed");

    if(team == 1) {
      playersBetOne.push(msg.sender);
      totalBetOne += msg.value;
    } else {
      playersBetTwo.push(msg.sender);
      totalBetTwo += msg.value;
    }
    
    players[msg.sender] = msg.value;
  }

  function claim(bytes32[] memory proof) public {
    require(merkleRoot != 0, "No winner yet for this bet");
    
    require(proof.verify(merkleRoot, keccak256(abi.encodePacked(msg.sender))), "You are not in the list");

    uint256 senderBet = players[msg.sender];

    uint256 totalWinners = totalBetOne;
    uint256 totalLosers = totalBetTwo;

    if(winner == 2) {
      totalWinners = totalBetTwo;
      totalLosers = totalBetOne;
    }

    uint256 total = senderBet + ((senderBet / totalWinners) * totalLosers);

    (bool success, ) = msg.sender.call{value:total}("");
  
    require(success, "Transfer failed.");

    emit GainsClaimed(msg.sender, total);
  }
}
```

Let's discuss different sections of it in detail.

```
import "@openzeppelin/contracts/access/Ownable.sol";
import {MerkleProof} from "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";
```

This imports the OpenZeppelin Ownable contract and the MerkleProof utility. You must previously install those dependencies by running NPM install "@openzeppelin/contracts" --save-dev. 
Our contract references the Ownable contract as we will use the onlyOwner condition in some methods. 

```
contract Betting is Ownable {
  event GainsClaimed(address indexed _address, uint256 _value);
```

The contract will emit an event GainsClaimed when someone with valid proof claims the gains. 

```
function setMerkleRoot(bytes32 root, uint8 team) onlyOwner public 
  {
    merkleRoot = root;
    winner = team;
  }
```
This is the method that we will call when the match finishes. We will pass the Merkle root computed from a tree with all the addresses that bet on the winner. We also pass the winner team. Also, note that this method is marked with the onlyOwner condition, so only the contract owner can set the root.

```
function getPlayersBetOne() public view returns(address[] memory) {
    return playersBetOne;
  }

  function getPlayersBetTwo() public view returns(address[] memory) {
    return playersBetTwo;
  }
```


These two methods return a list of the addresses that bet on each team. We will use these lists to compute the Merkle Tree. As these are views, they don't cost anything; they are simply resolved in our local ETH node. 

```
function bet(uint8 team) public payable {
    require(team == 1 || team == 2, "Invalid team");

    require(!checkPlayer(msg.sender), "You bet on a game already");
    
    require(msg.value >= minimumBet, "Minimum bet is 1 gwei");
    
    require(merkleRoot == 0, "Bets are closed");

    if(team == 1) {
      playersBetOne.push(msg.sender);
      totalBetOne += msg.value;
    } else {
      playersBetTwo.push(msg.sender);
      totalBetTwo += msg.value;
    }
    
    players[msg.sender] = msg.value;
  }
```
The method for betting on a team accepts the team as an argument and does two things,

1. Push the address on the correct list (Team A or Team B)
2. Increases the total amount for the bet associated with the contract

```
function claim(bytes32[] memory proof) public {
    require(merkleRoot != 0, "No winner yet for this bet");
    
    require(proof.verify(merkleRoot, keccak256(abi.encodePacked(msg.sender))), "You are not in the list");

    uint256 senderBet = players[msg.sender];

    uint256 totalWinners = totalBetOne;
    uint256 totalLosers = totalBetTwo;

    if(winner == 2) {
      totalWinners = totalBetTwo;
      totalLosers = totalBetOne;
    }

    uint256 total = senderBet + ((senderBet / totalWinners) * totalLosers);

    (bool success, ) = msg.sender.call{value:total}("");
  
    require(success, "Transfer failed.");

    emit GainsClaimed(msg.sender, total);
  }
}
```
Finally, the method for claiming the gains on the game. This method requires proof, which was previously computed from a Merkle tree containing all the addresses in the winner's list. If someone passes an invalid proof, or a proof calculated from some other tree, the method will validate that and reject the call.

```
require(proof.verify(merkleRoot, keccak256(abi.encodePacked(msg.sender))), "You are not in the list");
```

This method uses the following formula to distribute the gains.

```
uint256 total = senderBet + ((senderBet / totalWinners) * totalLosers);
```

# Generating the Merkle Tree

We will be using the merkletreejs and keccak256 from node.js with a Hardhat test suite to test our contract.

```
const { expect } = require("chai");
const { MerkleTree } = require('merkletreejs');
const keccak256 = require('keccak256');

describe("Betting", function () {
  let owner, addr1, addr2, addr3, addr4, addr5;
  let Betting, betting;
    
  beforeEach(async function() {
      [owner, addr1, addr2, addr3, addr4, addr5] = await ethers.getSigners();

      Betting = await ethers.getContractFactory("Betting");
      betting = await Betting.deploy();
      
      await betting.deployed();
  });
```

The code above deploys the contract and stores a few addresses provided by Hardhat in local variables so we can reference them later on in the tests.

```
it("Should allow claiming gains", async function () {
    await betting.bet(1, { value : 1e9 });
    
    await betting.connect(addr1).bet(1, { value : 1e9 })

    await betting.connect(addr2).bet(2, { value : 1e9 })

    const list = await betting.getPlayersBetTwo();

    const merkleTree = new MerkleTree(list, keccak256, { hashLeaves: true, sortPairs: true });

    const root = merkleTree.getHexRoot();

    await betting.setMerkleRoot(root, 2);

    const proof = merkleTree.getHexProof(keccak256(addr2.address));

    await expect(betting.connect(addr2).claim(proof))
      .to.emit(betting, 'GainsClaimed')
      .withArgs(addr2.address, 3e9);;
  });
```

The test above calls the "bet" method from three different addresses, giving a total of 3 gwei as the total balance. We also compute a Merkle tree from the list of addresses for team two (that's a single address, the address 2). 
It also generates proof for address 2, and calls the "claim" method with that proof to claim the gains. Note that it's crucial to impersonate the calls with the correct address using the connect method, as many of the methods in our contract use the msg.sender variable.

The complete code is available in my github repository ["merkletrees-smartcontracts"](https://github.com/pcibraro/merkletree-smartcontracts)

Merkle Trees have become more popular than ever in the last decade for their heavy use in the ...

Using Merkle Trees for Bulk transfers in Ethereum

# Developing a Dapp in Ethreum with Social Authentication using Next.js and Next-Auth-js

![alt](https://photos.collectednotes.com/photos/4455/e5a09a6b-2293-4f8f-a88f-cb3d72e6cb9f)

My last article [101 Smart Contracts and Decentralized Apps in Ethereum](https://auth0.com/blog/101-smart-contracts-and-decentralized-apps-in-ethereum/) discussed all the introductory concepts for developing Smart Contracts and Decentralized Applications in Ethreum. 

This article is focused on implementing a concrete sample that includes Smart Contracts and a Decentralized Application (DApp) written with Next.js.

The smart contracts in this article include a custom ERC-20 token and a Faucet. Don't worry if you don't know what those are. I am planning to give a short overview first.

## ERC-20

The acronym ERC stands for Ethereum Request for Comments. Those are Application-Level standards and conventions for Smart Contract development in Ethereum. They are available [here] (https://eips.ethereum.org/erc). 

Any new standard related to Smart Contract development (e.g., new tokens, wallet formats) is proposed through an ERC draft and eventually approved and released on that site.

ERC-20 is the standard for fungible tokens. Fungibility is the ability of an asset to be interchanged for another of the same type. If you have a token of the type "FOO", you can change it for another of the same type without losing any value. 

If you look into the specification, it is no other thing than an interface for a smart contract that represents a fungible token.

```
function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)
```
Suppose you take a Smart Contract and implement those methods using Solidity or any other language compatible with the Ethereum VM. In that case, your contract will adhere to the ERC-20 standard and can be considered a token.

Let's discuss those methods more in detail.
```
function name() public view returns (string)
function symbol() public view returns (string)
```
name and symbol are the name and symbol associated with the token. For example, a token "My Foo Token" with the symbol "FOO".

```
function decimals() public view returns (uint8)
```
Ethereum does not support decimals for amounts. Decimals is a workaround to express how many decimal positions a token supports. For example, 18 would mean a single token uses 18 zeros (1000000000000000000)
```
function totalSupply() public view returns (uint256)
```
It returns the total number/supply of available tokens. 
```
function balanceOf(address _owner) public view returns (uint256 balance)
```
It returns the balance for a given address.
```
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
```
These two allow transferring tokens from one address to another. 

```
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)
```
Approve allows allocating/lending some tokens to a third party (a different address, the spender). The owner of those tokens is taken from the sender address when the smart contract is invoked. This method is what we will use for our Faucet contract.
The other method, allowance returns the number of tokens allocated/lent to a given address by the owner. 

As you can see, a fungible token never leaves this contract. The available supply and owners are all reflected and stored on it.

## Minting vs. Mining
Minting and Mining are two terms often mention when talking about token issuance. 
ERC-20 are not native tokens in the ETH Blockchain; smart contracts represent them, so you can not obtain those as part of the mining process. You can only mine Ether.
On the other hand, minting is about issuing ERC-20 tokens, and it's usually part of the internal implementation of the smart contract. The initial supply can probably be minted in the Smart Contract constructor and updated later by other methods.

## A sample token

As part of this article, I decided to implement a fictitious token called "Cibrax". Here is the code.

```
// SPDX-License-Identifier: MIT

pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract CibraxToken is ERC20 {
    constructor(uint256 initialSupply) ERC20("Cibrax", "CIBRAX") {
        _mint(msg.sender, initialSupply);
    }
}
```
There isn't much to show here. I borrowed the ERC20 contract implementation from OpenZepellin and used that one as the base class for my contract. OpenZepellin distributes the contracts as a library via [NPM](https://www.npmjs.com/package/@openzeppelin/contracts). 

You provide the token name and symbol as part of the constructor and call the base method _mint to specify the initial supply. My implementation takes the initial supply from the constructor when you run the initial deployment. Also, the default value for decimals is 18, but you can optionally override that one too.

## Faucet
You might need tokens for paying gas or for any other operation in smart contracts. When you are in a production Blockchain, you can buy those or get them as rewards/fees from mining blocks. However, it does not make much sense to do the same in a testing network. Those networks provide Faucets, which are smart contracts for borrowing tokens.  There is no standard for the implementation of a Faucet. 
Here is a Faucet I implemented for the sample included with this article.

```
// SPDX-License-Identifier: MIT

pragma solidity ^0.8.4;

import "@openzeppelin/contracts/access/Ownable.sol";

interface ERC20 {
    function transfer(address to, uint256 value) external returns (bool);
    function name() view external returns (string memory);
    event Transfer(address indexed from, address indexed to, uint256 value);
}

contract Faucet is Ownable {
    uint256 constant public waitTime = 30 minutes;

    ERC20 public tokenInstance;
    
    mapping(address => uint256) lastAccessTime;

    constructor(address _tokenInstance) Ownable() {
        require(_tokenInstance != address(0));

        tokenInstance = ERC20(_tokenInstance);
    }

    function requestTokens(address _receiver, uint256 tokenAmount) onlyOwner public {
        require(allowedToWithdraw(_receiver, tokenAmount));
        tokenInstance.transfer(_receiver, tokenAmount);
        lastAccessTime[_receiver] = block.timestamp + waitTime;
    }

    function allowedToWithdraw(address _address, uint256 tokenAmount) public view returns (bool) {
        if(tokenAmount > 3) {
            return false;
        }
        
        if(lastAccessTime[_address] == 0) {
            return true;
        } else if(block.timestamp >= lastAccessTime[_address]) {
            return true;
        }

        return false;
    }

    function tokenName() public view returns (string memory) {
        return tokenInstance.name();
    }
}
```
This contract works like a private Faucet, as only the owner can transfer tokens to other addresses. I did this on purpose, so we can assign our Dapp as owner of the Faucet and only allow transferring tokens from it.  If someone wants to bypass the Dapp and send a transaction to this Smart Contract, it will be rejected. 

```
contract Faucet is Ownable {
```
The contracts inherit from the Ownable Smart Contract implementation from OpenZeppelin. This contract gives you access to a "onlyOwner" condition for methods, which means only the assigned owner can invoke them. In our scenario, the Dapp will be the assigned owner.

```
constructor(address _tokenInstance) Ownable() {
        require(_tokenInstance != address(0));

        tokenInstance = ERC20(_tokenInstance);
    }
```
The constructor ties the Faucet to any Smart Contract implementation that provides an ERC20 interface. In our example, we will assign our Cibrax token. You provide the address of the ERC20 contract, which can not be the empty address (address(0)) for deploying new contracts.

```
 function allowedToWithdraw(address _address, uint256 tokenAmount) public view returns (bool) {
        if(tokenAmount > 3) {
            return false;
        }
        
        if(lastAccessTime[_address] == 0) {
            return true;
        } else if(block.timestamp >= lastAccessTime[_address]) {
            return true;
        }

        return false;
    }
```
It checks for different conditions before any token is giving away. You can not ask for more than three tokens or do multiple calls within 30 minutes. These are vague conditions, but it shows a purpose. They prevent someone from exhausting all your available tokens.

## Testing our Smart Contracts
I decided to use the [HardHat](https://hardhat.org/getting-started/) tools to compile, test the contracts, and deploy them in an emulator. 

Hardhat uses ethers.js as the client library for connecting to a local ETH node, and Waffle as the testing framework.

```
describe("CibraxToken", function () {
    
    let owner, addr1, addr2, addr3, addr4, addr5;
    let CibraxToken, cibraxToken;
    let Faucet, faucet;
    
    before(async function() {
        [owner, addr1, addr2, addr3, addr4, addr5] = await ethers.getSigners();

        CibraxToken = await ethers.getContractFactory("CibraxToken");
        cibraxToken = await CibraxToken.deploy(1000);
        
        await cibraxToken.deployed();

        Faucet = await ethers.getContractFactory("Faucet");
        faucet = await Faucet.deploy(cibraxToken.address);
        
        await faucet.deployed();

        await cibraxToken.transfer(faucet.address, 500);
    });

    it("Deployment should assign a name", async function () {
        const name = await cibraxToken.name();
        expect(name).to.equal("Cibrax");
    });

    it("Deployment should assign a symbol", async function () {
        const name = await cibraxToken.symbol();
        expect(name).to.equal("CIBRAX");
    });

    it("Owner can transfer tokens", async function () {
        const amount = 100;

        const tx = await cibraxToken.transfer(addr1.address, amount)        ;

        const receipt = await tx.wait();

        const otherBalance = await cibraxToken.balanceOf(addr1.address);

        expect(amount).to.equal(otherBalance);
        expect(receipt.events?.filter((x) => {return x.event == "Transfer"})).to.not.be.null;
    });

    it("Faucet can transfer assigned tokens", async function () {
        const amount = 1;

        await faucet.requestTokens(addr3.address, amount);
        
        const balance = await cibraxToken.balanceOf(addr3.address);

        expect(amount).to.equal(balance);
    });

    it("Faucet returns token name", async function () {
        
        const name = await faucet.tokenName();
        expect(name).to.equal("Cibrax");
        
    });

    it("Faucet can not transfer more than assigned tokens", async function () {
        
        await expect(faucet.requestTokens(addr4.address, 5)).to.be.reverted;
        
    });
    
    it("Faucet can not transfer on consecutive calls", async function () {
        const amount = 1;

        await faucet.requestTokens(addr4.address, amount);
        
        await expect(faucet.requestTokens(addr4.address, amount)).to.be.reverted;

    });

    it("Faucet can transfer allowed tokens", async function () {
        
        const allowedAmount = 5;
        const amount = 1;

        await cibraxToken.approve(faucet.address, allowedAmount);
        
        await faucet.requestTokens(addr5.address, amount);
        
        const balance = await cibraxToken.balanceOf(addr5.address);

        expect(amount).to.equal(balance);
    });

});
```

The "before" method is used for test initialization. It deploys the ERC-20 and Faucet contracts, and obtains their address. The other methods describe the tests.

```
 it("Faucet can transfer allowed tokens", async function () {
        
        const allowedAmount = 5;
        const amount = 1;

        await cibraxToken.approve(faucet.address, allowedAmount);
        
        await faucet.requestTokens(addr5.address, amount);
        
        const balance = await cibraxToken.balanceOf(addr5.address);

        expect(amount).to.equal(balance);
    });
```

For example, the test above uses the "approve" method in our custom token to pre-assign or authorize some tokens to the Faucet (five tokens in total). To be clear, the tokens are not directly assigned to the Faucet, but it allows the Faucet to use them.
The Faucet later transfers one of those tokens to an ETH address (addr5), and the balance on that address is verified.

For compiling the contracts and running the tests, you can run these commands in a console.

```
npx hardhat compile
npx hardhat test
```

## Dapp

The Decentralized App or DApp, in short, it's the visible layer for our Faucet. 

It's implemented in Next.js and leverages Next-Auth.js for authentication with social providers.

The .env file is used to assign the address of the Faucet and private key to our application.

```
ETH_NODE_URL=http://127.0.0.1:8545/
ETH_FAUCET_ADDRESS=<address>
ETH_PRIVATE_KEY=<private key>
```

If you want to deploy the contracts in the local Hardhat emulator, you can run the script "cibraxtoken-deploy.js" under contracts/scripts. That script will return the address of the contracts. Also, Hardhat always uses the first address from the available accounts in the emulator for deploying the contracts, so you can take the private key from that account and configure it in the Next.js app.

### User authentication

The main page in our application uses the Next-Auth.js react hooks for coordinating the sign-on process.

```
import Head from 'next/head'
import { TokenForm } from './components/TokenForm';
import { signIn, signOut, useSession } from 'next-auth/client'

export default function Home() {
  
  const [ session ] = useSession()
    
  return (
    <div className="flex flex-col items-center justify-center min-h-screen py-2">
      <Head>
        <title>Faucet with Social Auth</title>
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className="flex flex-col items-center justify-center w-full flex-1 px-20 text-center">
      <p className="mt-3 text-2xl">
        
        You can use this Faucet to request Cibrax tokens
      </p>
        
      {session && <TokenForm session={session}/>}

      <p className="mt-3 text-2xl">
        {(session) ? 
          <button onClick={() => signOut()} className="shadow bg-blue-500 hover:bg-blue-400 focus:shadow-outline focus:outline-none text-white font-bold py-2 px-4 rounded">Logout</button> : 
          <button onClick={() => signIn()} className="shadow bg-blue-500 hover:bg-blue-400 focus:shadow-outline focus:outline-none text-white font-bold py-2 px-4 rounded">Login</button>
        }

    </p>  
      </main>
    </div>
  )
}
```
The useSession hook returns the existing user session if there is one. If no session is available, we can display the Login button and assign the signIn hook to it. This method will do the sign-on handshake with the social providers.

### Smart Contract Calls

The integration with the Smart Contract is done server-side through an API. 

```
import type { TransactionResponse } from '../types'
import type { NextApiRequest, NextApiResponse } from 'next'
import { getSession } from "next-auth/client"
import { ethers } from 'ethers';

import artifact from '../../contracts/Faucet.json';

const url = process.env.ETH_NODE_URL;
const privateKey = process.env.ETH_PRIVATE_KEY || "";
const faucetAddress = process.env.ETH_FAUCET_ADDRESS || "";

const provider = new ethers.providers.JsonRpcProvider(); 

const wallet = new ethers.Wallet(privateKey, provider);
const faucet = new ethers.Contract(faucetAddress, artifact.abi, wallet);

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse<TransactionResponse>
) {

  const session = await getSession({ req })

  if(!session) {
    res.status(401);
    return;
  }

  if(!req.body.address) {
    res.status(400);
    return;
  }

  await faucet.requestTokens(req.body.address, 1, {
    gasPrice: 25e9
  });

  res.status(200).json({ successful: true })
};
```

This API does two things,
It connects the Faucet contract using ether.js. The settings for connecting to the node are retrieved from the .env file. 
It checks the user session from Next-Auth.js. If the user is not authenticated, it returns 401. Otherwise, it makes a call to the Faucet to transfer tokens.
 
## Get and Run the code
The complete sample is available to download from this Github repository - [social-faucet](https://github.com/pcibraro/social-faucet)

 

alt

My last article 101 Smart Contracts and Decentralize...

Developing a Dapp in Ethreum with Social Authentication using Next.js and Next-Auth-js

# Hybrid Contracts, Oracles and Chainlink

If you already got a chance to review how smart contracts work in a Blockchain like Ethereum, you would understand they run in an isolated fashion. 
The Ethereum VM executes the contracts in a sandbox, making it impossible to use any data or feature not accessible from the network or any other smart contract.

The idea of Oracles comes into the picture here. The term Oracle became popular right after The Matrix movie. It was the lady who knew everything about the Matrix and told Neo, the main character, about what was happening in the outside world. Following the same analogy, an Oracle is a smart contract that knows how to connect with applications or services running outside of the Blockchain.

Oracles represent a critical path for DEFI apps. In most cases, they connect to different external price feeds and provide price data to other contracts running in the network. 

A Hybrid contract is another term used by many in this context. It refers to a combination of a Smart Contract (code that runs on-chain) and off-chain services provided by a Decentralized Oracle Network (or DoN in short).

>> As Sergey Nazarov, one of the Chainlink's Founders, would say once. One Blockchain without Oracles, it's like a computer without the internet.

# The Push and Pull Models

The push and pull models refer to the way an Oracle can feed data to other contracts. 

In the push model, applications or DApps (Decentralized Apps) running outside the Blockchain push and store data in Smart Contracts, which other contracts reference later on-demand.

In a pull model, a contract calls an Oracle to retrieve external data. The Oracle then uses different mechanisms to connect with the outside, call an API and push back any result. This model works more like an async callback. A contract submits a transaction in the Blockchain targetting the Oracle Smart Contract.  A DApp running outside uses the data in that transaction to call an external API or run any computation and pushes the result back as another transaction for the original contract.

# Chainlink

Chainlink is a project whose aim is to provide all the infrastructure and plumbing for running a network of Oracles that integrate with existing Blockchain networks (Ethereum and others). It's not a Blockchain, but it offers the infrastructure to run heterogeneous networks with oracle nodes that act as intermediaries between Smart Contracts and applications running outside.

The value proposition or business value in Chainlink is to offer a mechanism to sell data to apps running in the Blockchain. If you have an API that provides data that might be useful in the Blockchain, you can publish it through a Chainlink's adapter in one or more nodes and get paid for every request made to it. The unit of payments is a LINK token, which is a standard ERC-677 token.

You can run one or more nodes or ask any existing node operators (service providers that run nodes in their infrastructure) to run the adapter for you. 

In that sense, Chainlink represents a collection of decentralized oracle networks with nodes hosting different adapters or connections with external applications.

One of the critical aspects of implementing autonomous apps that run in a Blockchain is that they can not rely on a single data source to make decisions.  If the data source becomes unavailable or starts providing inaccurate information, it suddenly becomes a big mess.
Chainlink tries to address that issue by aggregating data from multiple sources and making it available through various nodes (horizontal scaling). If one node becomes unresponsive, the other nodes can take that work. The same thing with the data sources is that if one starts providing invalid data, they can still correct it by using other sources.  

It's worth mentioning that Chainlink does not offer or enforce any mechanism for data aggregation. You are responsible for implementing that feature when you connect Chainlink with one or more APIs through an external adapter. We will discuss what an external adapter is in the next section.

Based on the documentation available on the Chainlink's website. It looks like the two revenue streams for the projects are related to Price Feeds and Generation of Random numbers (useful for gaming and gambling)

## Chainlink Architecture

![alt](https://photos.collectednotes.com/photos/4455/30fbf6a3-6905-410f-b7c1-6320f3add7c0)

At a high level, a Chainlink network is run by nodes. A node is a daemon process that hosts integration jobs and connects to the Blockchain. When you start a node, you must provide a private key for signing any transaction submitted to the Blockchain. If you don't provide one, the node will generate one automatically for you.  
You also need to fund that key with ETH, or otherwise, the node will not be able to pay any gas. The private key also gives you a public address for identifying your node.

You use **jobs** to integrate your running node with the Oracles in the Blockchain. Those jobs are configured as json documents.

A job contains two parts, an initiator and a collection of tasks. An initiator is a component that watches up for a given condition to happen to kick off the job. Chainlink already offers a set of initiators you can use out of the box in a job or create your initiator otherwise. 

Initiators watch out for different conditions to kick off jobs. Some of them, for example, look for events emitted on the Blockchain or transactions in the transaction log. Others just run jobs on-demand or in a given interval of time. The former are used to support a push model with a job running and pushing data to a smart contract.  The latter are used to support a pull model with a job reacting to an event and pushing data to a contract afterward.

Once a job is started, it runs a set of tasks to convert the input data coming from the initiator into an output that can be pushed to the Blockchain. One of those tasks can be an adapter, which can connect to an external system or API to pull data. 

This is an example of a job,

``` javascript
{
  "name": "Call my adapter",
  "initiators": [
    {
      "type": "web"
      }
    }
  ],
  "tasks": [
    {
      "type": "myadapter"
    }
  ]
}
```

The web initiator allows launching the job from a web interface in the node. Once the job is launched, it calls a custom adapter "myadapter", which probably pulls data from an API.

As you can see, a job follows the Pipeline pattern, with an input and several tasks that convert that input into an output. 

A node provides two interfaces for configuring jobs and adapters. A cli tool that can be run from a terminal, or a web application that can hit from a web browser. Both require a username and password that must be assigned when the node is initially configured.

### External Adapters

An external adapter is a component that allows the integration between Chainlink and external applications/systems. 

Adapters must be previously registered in the node to be used in a job. An adapter is no other thing than an API that follows a convention for the input and output data.  When you register it in the node, you only have to specify a name and the URL where it's listening. You later reference it by name in the jobs. 

An adapter can only accept HTTP POSTs with the following json payload,

```javascript
{"data":{}, "meta": {}, "id": "<job id>", "responseURL": "<url>"}
```

* data: any input argument to be used by the API
* meta: optional metadata arguments.
* responseURL: optional, will be supplied if job supports asynchronous callbacks
* id: optional, the job id.

It must return with the following json payload,

```javascript
{"data": {}, "error": {}, "pending": true|false}
```

* data: any response data returned by the API
* error: optional,  any error information.
* pending: optional, the API requires an asynchronous callback.

This does not use HTTP error codes at all, and relies on a payload element to detect if the API call failed or not. 
Also, if the API requires authentication, you will have to configure the credentials or keys in the adapter through standard configuration files (.env) or environment variables in the node, or pass them via a job specification as parameters. 

At the time of writing this post, a Node will not provide any authentication token to the adapter. If you don't want anyone to call your adapter, you probably have to host it in the same subnet as the node, or do IP restrictions.

## Running a Chainlink node

You can run a Chainlink node directly from the source code or  Dockers images. 

In this post, I am going to show how to do it from Docker. You will require two things to run a Node container from a Docker image,

* A Postgres db.
* An ETH Node or a Connection to a public node like Infura.

For the Postgres DB, you can also run it as a docker container.  What I am going to show here uses a docker network to communicate the two containers.

1. Create the docker network first

```
docker network create chainlink-net
```

2. Run the Postgres DB container using the network created in the step #1

```
docker run -d -p 5432:5432 --name chainlink-db --net=chainlink-net -e POSTGRES_PASSWORD=password postgres
```

3. Create the node configuration file (.env file). That's a text file with these settings (This uses the Rinkeby testnet).

```
LOG_LEVEL=debug
ETH_CHAIN_ID=4
MIN_OUTGOING_CONFIRMATIONS=2
LINK_CONTRACT_ADDRESS=0x01BE23585060835E02B77ef475b0Cc51aA1e0709
CHAINLINK_TLS_PORT=0
SECURE_COOKIES=false
GAS_UPDATER_ENABLED=true
ALLOW_ORIGINS=*
ETH_URL=<YOUR INFURA Rinkeby ETH URL>
DATABASE_URL=postgresql://postgres:password@chainlink-db:5432/postgres?sslmode=disable
 ```

4. Run the Chainlink Node Container

```
docker run -v ~/.chainlink-rinkeby:/chainlink -p 6688:6688 -it --net=chainlink-net --env-file=.env smartcontract/chainlink:0.10.8 local n
```

This will start the container in interactive mode. It will prompt you for an username and password for the admin console, and also a password for the Node private key. 

The web application for the Admin dashboard assigned to the node will be publised in the port 6688.

Once the Node container starts running, you can navigate to https://localhost:6688 and start configuring adapters and jobs.

If you want to export the private key and associate with the funds, it can be done from command line with the CLI tool.

1. Connect to the container in Bash mode

```
docker exec -it <container> bash
```

2. Run the following commands

```
chainlink admin login
chainlink keys eth list
chainlink keys eth export <node-address> -p .password --output key.json
```

You will need the Node address, which is shown when the node starts up or also in the web console, and a file with the private's key password. The output will be a json file that you can import into a wallet like Metamask.

If you already got a chance to review how smart contracts work in a Blockchain like Ethereum, you would ...

Hybrid Contracts, Oracles and Chainlink

# Como emigrar a España como trabajador remoto

España ha siempre representado una via de entrada al viejo continente para muchos, especialmente para los Argentinos y muchos de los paises de sudamerica. No existe barrera idiomatica, lo cual facilita las cosas y muchos han podido tramitar el pasaporte europeo por descendencia directa.

Para los que no tuvimos esa suerte, aun existe una forma que muchos no conocen y sirve para los trabajamos en forma remota. La visa de residencia no lucrativa, la cual le permite a uno quedarse mas de 90 días en el país, y obtener la residencia permanente luego de 3 años. 

La ventaja de esta visa es que no se requiere que una empresa que esponsoree la visa, y uno la puede tramitar por su cuenta. Lo que España quiere es limitar inmigración que compita con mano de obra local, pero no es el caso para trabajadores remotos. Tampoco requiere ninguna inversion en el pais. 
Por ultimo, obteniendo esta visa, también se puede traspasar a los dependientes directos, esposa e hijos.

Este tipo de visa tiene dos condiciones,

- Uno tiene que demostrar que tiene los suficientes medios económicos para vivir en el país. 
- Un seguro medico privado con cobertura total sin copagos para que uno no utilice el sistema publico de salud.
- No tener antecedentes penales en el país o tener prohibición para ingresar a Europa.

## Medios Economicos

Para cumplir con esta condición se debe tener al menos el 400% de [IPREM](https://es.wikipedia.org/wiki/Indicador_P%C3%BAblico_de_Renta_de_Efectos_M%C3%BAltiples) (Indicador Público de Renta de Efectos Múltiples) en una cuenta bancaria, que es un índice de referencia, empleado en España, para la concesión de ayudas subvenciones o el subsidio de desempleo. Al momento de escribir esta nota, es alrededor de 26 mil euros anuales. 
Posiblemente exigían los extractos bancarios de los últimos seis meses.

## Seguro Medico

Tiene que provenir de una empresa española que solo opere en el pais, y debe tener al menos un año de duracion. Debe incluir todas las especialidades del sistema sanitario público español y tener cobertura total sin copagos.

## Como se solicita

El tramite se debe iniciar en el consultado de España en el pais en donde uno viva, no puede iniciarse en España.
Para ello hay que enviar la siguiente documentacion y esperar al menos un mes a que se tome una resolucion.

- [Formulario de visa nacional] (http://www.exteriores.gob.es/Embajadas/OTTAWA/Documents/Solicitud%20de%20visado%20nacional%20-%20Espa%C3%B1ol.pdf)
- [Modelo de solicitud Ex 01](http://www.exteriores.gob.es/Consulados/HOUSTON/es/ServiciosConsulares/Documents/EX01.pdf)
- Seguro médico emitido por la empresa privada española.
- Resumen bancario o carta del banco demostrando que se tiene mas de 26000 euros al año. 
- Fotos de 3×4 cm con fondo blanco.
- Pasaporte original.
- Certificado médico, demostrando que no tiene ninguna enfermedad que le impida a uno el ingreso al pais.
- Certificado de antecedentes penales

> Disclaimer, no soy abogado ni realizo este tipo de tramites. Si necesitan asesoramiento, mejor consulten a un especialista en el tema.






España ha siempre representado una via de entrada al viejo continente para muchos, especialmente pa...

Como emigrar a España como trabajador remoto

# Como cobrar en Argentina por exportacion de software

Digamos que consiguieron un trabajo remoto para una empresa fuera del país, con un buen sueldo en dólares, con eso ya tienen sorteado el mayor de los inconvenientes. 

Cobrar por ese trabajo ya resulta una cosa menor, y te voy a explicar algunas cosas a tener en cuenta.

En primer lugar tenes que estar inscripto ante la afip. En este punto vas a necesitar asesoramiento de un contador para que te diga que mas te conviene. Si nunca facturaste, seguramente te va a decir que te inscribas el monotributo. 

El monotributo funciona por escalas o categorías de facturacion, que llevan nombre de letra consonante y van desde la letra A hasta la H. Cuanto mas se factura, mas alta la categoria, y mas se paga, es un monto fijo mensual por categoria. Esto tiene un límite, que al momento de escribir esta nota es cerca de 18 mil dólares oficiales anuales. Si se supera esta categoria, uno ya pasa al regimen de ganancias como responsable inscripto, y ahi debe pagar según escalas de ganancias, pero calculen como máximo un 35% de lo que recauden. Tambien pidanle al contador que les habilite la posibilidad de emitir facturas E de exportacion en forma electronica.

Por otro lado está ingresos brutos, que representa cerca de un 2% de lo facturado. Creo que el mismo puede ser obviado si uno tiene domicilio en la ciudad de Buenos Aires o bien, tiene título universitario en sistemas.

Segundo paso, tener una cuenta bancaria. Por ahora solo les va a servir tener una cuenta en pesos, no se puede recibir transferencias en una cuenta en dólares. Por otro lado, el banco tiene que operar con comercio exterior, no pueden ir y abrir la cuenta en cualquier banco, este punto es primordial. Y tercero y ultimo, averiguen bien si comercio exterior soporta liquidar las órdenes de pago en forma online. De lo contrario, los van a hacer ir a la sucursal por cada pago que reciban, y lo peor es que el banco central solo te da 5 dias habiles para liquidarla. Ya me ha pasado con un banco que tuve por años y fue todo un parto.

Cuando reciban el pago, la plata no va a entrar directamente a su cuenta, va a quedar en lo que llamo, el limbo, hasta que ustedes ejecuten una liquidación de orden de pago. Es ahi donde el banco basicamente pesifica todo lo que recibieron al valor del dólar oficial y lo deposita en sus cuenta. Como dije anteriormente, por orden del banco central solo tienen 5 dias para hacer esto. La liquidación consiste en llenar una declaracion jurada justificando el origen de los fondos, y presentar una factura de exportación E que tenga exactamente el mismo monto de lo que recibieron (si no es el mismo, se la rechazan). Con todo esto, o bien lo ingresan en forma online o lo presentan en forma física en el banco, y con eso solo les queda esperar a que lo liquiden y les den pesos.

Cosas que no pueden hacer.

- Omitir la factura E o no presentar la liquidación en el banco. Los pueden multar y nunca van a recibir los fondos.
- Emitir la factura E pero cobrar en una cuenta en el exterior. Esto se considera delito grave y estarían incumpliendo la ley de cambio del banco central.

Y por ultimo, recuerden que la AFIP tienen convenio de informacion con casi todos los fiscos del mundo, si reciben una transferencia en una cuenta no declarada, posiblemente se enteren.







Digamos que consiguieron un trabajo remoto para una empresa fuera del país, con un buen sue...

Como cobrar en Argentina por exportacion de software

# Como emigrar a Estados Unidos siendo programador o emprendedor tecnologico

Desde los comienzos de mi carrera como programador, siempre vi a Estados Unidos y mas especificamente, Sillicon Valley, como la meca que uno deberia alcanzar. 

Al principio cuando uno recien comienza, lo ve como algo imposible, lo que uno quiere es juntar experiencia, y por otro lado, esta la barrera idiomatica, no cualquiera nace dominando el idioma ingles.

Yo soy de Argentina, y si uno suma la inestabilidad economica que se viene sufriendo en el pais desde años y las trabas que uno encuentra para progresar, eso aumenta en forma exponencial las ganas de lograr esa meta. Por un tiempo se volvio una obsesion para mi y evalue miles de posibilidades. 

La idea de esta nota es contarles un poco lo que fui aprendiendo y las muchas posibilidades que se fueron abriendo en este ultimo tiempo.

# El idioma

Quizas algo no tan basico, pero el primer paso es dominar el idioma. Ojala alguien me hubiera dicho o aconsejado cuando era joven que aprendiera ingles. Yo fui criado en una familia de clase media en Buenos Aires, fui a un colegio industrial, y lo poco que aprendi de ingles inicialmente fue ahi, ingles tecnico y basico. Lo justo y necesario para leer y comprender algunos articulos, pero no mas que eso. En mi epoca tambien aprendi mucho jugando a las denominadas aventuras graficas, que se distribuian en el pais mayormente en ingles, Monkey Island, Maniac Mansion, y demas. 

Me recibi en 1999, y ahi nomas empece a buscar trabajo como programador junior, por suerte consegui algo a los meses.
Luego, en el 2003, como otro golpe de suerte, pude unirme a una consultora que recien daba sus primeros pasos, Lagash Systems, pero que habian conseguido algo inedito para ser una empresa de aca, exportarle servicios de desarrollo de software a la mismisima Microsoft, y en particular, al equipo de Patterns & Practices en Redmond. Primer gobierno de Kirchner, un dolar bajo, y eso comenzaba a ser un buen negocio para cualquiera que quisiera exportar.

Ahi fue donde me di el primer golpe contra la pared, me asignaron un proyecto para desarrollar un building block para .NET, el cual requeria interaccion directa con el equipo en Redmond. Mi ingles era tan limitado que a duras penas podia escribir un mail, imaginense lo que era ademas tener que estar en un reuniones con llamadas telefonicas (si, no existia skype, zoom, ni google meet, era todo por telefono de linea). 

Eso me forzo a dar mis primeros pasos y empezar a tomar clases de ingles particular. Otra cosa que tambien me ayudo mucho fue empezar a escribir blog posts en ingles. 

En el 2006, tuve la oportunidad de recibir una oferta para trabajar para el Banco Inter-America de Desarrollo en Washington DC por el transcurso de un año, y bueno, esa experiencia termino afianzando el idioma.

Conclusion, inviertan parte de su tiempo en aprender ingles, a la larga es lo que mas paga. Tomen clases particulares, formen parte de grupos de aprendizaje, leean libros, escriban articulos o notas, etc.

## Emigrar a los Estados Unidos

Estados Unidos es quizas uno de los paises que mas trabas pone para desalentar la inmigracion. No es imposible, pero tampoco es algo facil que cualquiera pueda hacer.
Les voy a comentar las distintas alternativas que fui evaluando y aprendiendo a lo largo de mi carrera.

### Visa H1B

La visa H1B es para trabajo esponsoreado por una empresa en los Estados Unidos. Permite un camino directo a la residencia, y obtener una green card.  Es la visa ideal para cualquiera que quiera immigrar, pero tambien una de las mas dificiles de obtener. Estados unidos ofrece un limite de visas H1B que otorga en un año, el cual es 65000, y 20000 extras para lo que cuentan con Master Degree o PH. Por lo general, ese numero no alcanza a cubrir la cantidad de solicitudes que se generan, por lo cual se termina entrando en un sorteo (salvo que uno haya solicitado esto en el 2008 cuando el pais estaba sumamente quebrado como fue mi caso). Para que una empresa pueda solicitar esta visa para un empleado, primero, debe justificar que no fue capaz de encontrar mano capacitada en los Estados Unidos para cubrir la misma posicion, y segundo, tienen mas prioridad los que alcanzaron un titulo universitario. No es algo que se exiga, pero siempre es bueno ternerlo, por eso tomen nota, primero aprender ingles, y segundo, traten de terminar una carrera universitaria. 

Por otro lado, es muy dificil que una empresa esponsoree una visa directamente a alguien que no conozca, el proceso es tedioso, costoso y demora mas de un año, por lo cual, salvo que la empresa este muy desperada por conseguir a alguien que sepa algo especifico, no lo van a publicitar por ahi. 

Para esto ultimo, se vuelve muy importante el networking, participen de comunidades, escriban codigo open source, articulos, blog posts, cualquier cosa que los lleve a conocer gente nueva. Esa es una forma, y la cual utilice yo en principio. Trabajar en forma remota y hacerse conocido es otra manera y capaz mas de aplicar hoy en dia.

### Visa L1

La visa L1 es otra visa esponsoreada, pero es para transferir empleados desde una sucursal fuera de los Estados Unidos a los Estados Unidos. Tambien ofrece camino directo a la residencia y la ventaja es que no tiene limite y es mas facil de tramitar. 

Esta visa es una muy buena oportunidad que se logra basicamente trabajando para alguna empresa grande o startup que tenga un centro de desarrollo en Argentina. Para dar un ejemplo, Mulesoft/Salesforce, Microsoft o Auth0, para estas empresas tengo conocidos que pasaron por ese proceso. En el caso de Microsoft, hay otro punto importante, debido a la pandamia del Covid-19, se abrio la oportunidad de que equipos en Redmond contraten gente directamente en forma remota en Argentina, a traves de la subsidiaria local, por lo cual facilita mucho las cosas para este tipo de visa.

Para emprendedores, este es otro camino, si uno tiene su empresa en Argentina, y quiere abrir una sucursal en los Estados Unidos, uno mismo se puede tramitar la Visa L1. De todas formas, es complicado, inicialmente, se otorga por un año, y luego de ese periodo, uno tiene que demostrar que el negocio crecio y contrato mano de obra en los Estados Unidos. Si estas condiciones no se cumplen, la visa se cancela. Por ese motivo, siempre es mas facil ingresar a la visa L1 por el primer camino, una empresa que haga esto por nosotros.

### Visa G4

La visa G4 es muy rara, es una visa diplomatica y es la que el Banco Inter-Americano me dio en 2006. No tiene cupo o limite, y uno al mes ya puede estar viviendo en los Estados Unidos. Ofrece camino directo a la residencia, y otro punto no menor, es que mientras uno tenga esa visa no es considerado residente de los Estados Unidos y por ende no esta obligado a pagar impuestos en dicho pais. He escuchado el caso de muchos empleados del banco que nunca terminaron sacando la green card y convirtiendose residentes para no pagar impuestos.

Cuando yo ingrese al banco, fue por suerte y por un conocido que ya trabajaba en el mismo. Hoy el dia, el banco siempre publica posiciones en Linkedin, y otro que hace lo mismo es el World Bank.

### Visa O1

La visa O1 es otra visa esponsoreada que no tiene limite o cupo, pero se otorga a personas con habilidades especiales. Muy dificil de conseguir, la empresa tiene que demostrar que la persona es un genio en algo o ha hecho alguna contribucion que lo convierte en alguien unico.

### Visa E2

La visa E2 para emprendedores es algo que muchos no conocen, y es por convenio entre los Estados Unidos y algunos paises. La Argentina por suerte entra dentro de dicho convenio. 
Esta visa se otorga a personas que quieran invertir en un negocio en los Estados Unidos, pero tiene que ser una inversion demostrable y mayor a las 100.000 dolares, cuanto mas grande, mas oportunidad de que a uno se la otorguen. Esta visa tiene 2 problemas.

1- No tiene camino directo a la residencia. No se puede obtener la green card. Uno paga impuestos en los Estados Unidos y nunca se le garantiza que se pueda quedar a vivir ahi. Si una persona tiene hijos, al cumplir los 18 años deben abondar el pais u obtener una visa para poder quedarse.

2- Tiene que hacer una inversion demostrable. Por ejemplo, si uno quiere abrir una startup tecnologica o consultora, tiene que demostrar que gasto mas de 100.000 dolares en algo, no sirve simplemente abrir una oficina y tener esa plata en una cuenta de banco, uno la tiene que invertir en algo. 

Esta visa le permite a uno trabajar en otra cosa que no este ligada a la inversion, por lo que muchos hacen es invertir en un negocio o franquicia para solo obtener la visa y luego trabajar en su rubro para una empresa local en los Estados Unidos.

### Visa EB5

La visa EB5 es para gente con mucho poder adquisitivo y dudo que sea para alguno de los que estan leyendo esta nota. Uno puede invertir cerca de un millon de dolares en alguno negocio o empresa en los Estados Unidos y de esa forma obtener la green card en forma directa. 

### Visa F1

La visa F1 le permite a uno poder inmigrar a Estados Unidos para poder estudiar en una universidad privada. No es camino a la residencia, y tampoco le da a uno la posibilida de poder trabajar. Pero sin embargo, uno puede saltar a la visa H1B si encuentra una empresa que lo esponsoree, y esto no entra en el cupo de los 65.000, por lo cual es una opcion que muchos contemplan.





 







Desde los comienzos de mi carrera como programador, siempre vi a Esta...

Como emigrar a Estados Unidos siendo programador o emprendedor tecnologico

# Trabajar en forma remota desde la Riviera Maya

Hace unos años, exactamente en el 2016, luego de trabajar casi 8 años continuos en forma remota desde Buenos Aires, mi esposa y yo decidimos que queriamos un cambio de vida y experimentar otra cosa junto a nuestros hijos.

Como el sueño de muchos, y nuestro tambien, siempre quisimos saber como seria vivir junto a una playa los 365 dias del año. 

Analizamos varios de los siguientes factores,

- Clima. Tenia que ser ideal todo el año y no solo los pocos meses de verano.
- Residencia. Tenia que ofrecer facilidades para tramitar la residencia en caso de que decidieramos quedarnos y dar la bienvenida a inmigrantes. Descartamos de lleno a todos los lugares que ofrecian trabas para esto. Recuerden, era 2016, y la idea de nomades digitales aun no estaba instalada en casi ningun pais, es algo que surgio debido a la pandemia de covid-19.
- Idioma. Queriamos que la adaptacion fuera facil y por eso solo evaluamos lugares con habla castellana o inglesa.
- Costos de vida. No buscabamos lugares caros, queriamos mantener mas o menos el mismo nivel de vida que en Buenos Aires en cuestion de gastos y alojamiento.

Luego de evaluar varias alternativas, 
nos decidimos por Mexico, y mas especificamente, la Riviera Maya.

# Visa de estadia larga

Mexico no exige visa de turista. Como turista uno puede permanecer 6 meses y no hay camino directo a la residencia. 
Si uno plenea algo a largo plazo, lo ideal es ingresar con una visa de estadia larga, la cual permite quedarse en el pais maximo cuatro años de corrido y luego solicitar la residencia. La misma se renueva en forma anual y no permite ser empleado en Mexico, lo cual es ideal para trabajadores remoto.

El proceso para obtener la misma inicialmente no fue muy complicado. Uno se presenta en la embajada de Mexico en su pais, previo turno, y solicita la visa de estadia larga. Les van a pedir un pasaporte, fotos y demostracion de ingresos que le permitan estar en Mexico y poder vivir sin tener que tomar ningun empleo en el pais. Ahi uno debe mostrar los ingresos provenientes de su trabajo remoto. Al cabo de dias, me devolvieron el pasaporte con una visa estampada.

La parte complicada empieza ahora. Una vez que uno ingresa a Mexico con esa visa, tiene maximo 30 dias para ir a inmigraciones y solicitar lo que ellos denominan un canje, que no es otra cosa que el documento nacional de identidad en ese pais. Lo complicado es que uno debe presentar un domicilio de residencia, con una factura de servicio  y eso implica que uno ya haya encontrado y alquilado un lugar para vivir. No sirve un AirBnB o un hotel, y conseguir un lugar que se alquile a largo plazo en una zona turistica y que le guste a uno no es tarea facil. Existen varias en donde uno puede quedarse, el centro de Cancun, mas residencial y a unos 15 minutos de la playa, la zona hotelera de Cancun, lo mas parecido a Miami que uno puede encontrar, con playas mayormente ocupadas por edificios y hoteles, o un poco mas alejado, pueblos mas tranquilos, Playa del Carmen, Puerto Morelos o Tulum. Tambien hay islas, la Isla Mujeres enfrentada Cancun o Cozumel, enfrentada Playa del Carmen, pero las descartamos desde un principio por un tema de mobilidad. 

En nuestro caso, nos terminamos decidiendo por la zona hotelera, y tuvimos la suerte de conseguir un departamento expectacular con vista al mar caribe a los pocos dias de comenzar la busqueda, ya que fuimos fuera de temporada. Segun nos dijieron, en temporada alta (de Diciembre a Marzo), esos departamentos vuelan y no se consigue nada. La conexion a internet tambien es importante para poder trabajar. En el caso de la zona hotelera, al ser zona exclusiva de hoteles, la conexion era por fibra optica y con un ancho de banda cercano a los 1000mb,  mucho mejor de lo que uno puede conseguir en Buenos Aires.

![alt](https://photos.collectednotes.com/photos/4455/63a837ba-68f1-4f17-a95f-63123c06dd48)

Otro punto importante es que una vez que se activa el canje, inmigraciones tiene de 30 a 60 dias aproximadamente para entregar el documento final, y por ese periodo uno no puede salir del pais salvo casos de fuerza mayor, los cuales deben ser justificados tambien en inmigracion para obtener un permiso que te deje salir del pais. 

En el caso de una familia, el canje lo hace unicamente el aplicante principal, y una vez obtenido el tramite final, se debe comenzar un proceso similar para el resto de la familia.

# La vuelta

En nuestro caso, no nos terminamos adaptando y volvimos a Buenos Aires a los 6 meses. De todas formas, fue una experiencia increible que nos dejo muy buenos recuerdos y de otra forma no hubieramos podido realizar







 

Hace unos años, exactamente en el 2016, luego de trabajar casi 8 años continuos en forma remota d...

Trabajar en forma remota desde la Riviera Maya

#Authorization Code Flow with PKCE in Azure AD with React

## Authorization Code Flow with PKCE

The implicit authorization code flow was initially released for native/dumb and javascript applications running in a context of a browser that did not have a dedicated backend to negotiate an access token from an authorization server (due to a limitation in browsers that prevented JavaScript from making cross-domain calls) . 

In this flow, access tokens were returned directly to the browser without requiring any client secret. These aspects made it naturally less secure, so additional practices were used to mitigate any potential vulnerability (e.g short lived tokens, pre-registered redirection URIs or a set of a unique nonce and state parameters in the URL)

Nowadays, most browsers support Cross-Origin Resource Sharing (CORS) so that cross-domain call limitation is not longer an issue. PCKE or Proof of Code Key Exchange leverages CORS in the browser to negotiate an access token in two steps.

A code is negotiated in the first step with the following request,

```
HTTP GET https://AzureADURL/authorize 
&response_type=code 
&redirect_uri=https://localhost:3000/login 
&scope=openid profile
&client_id=..... 
&code_challenge=......
&code_challenge_method=S256 
```

And a second step is executed to get the actual access token,

```
HTTP POST https://AzureADURL/token
&code=.....
&client_id=.... 
&grant_type=authorization_code
&code_verifier=....
&redirect_uri=https://localhost:3000/login
```

The code returned in the first call is the result of a cryptographic algorithm computation (hash) from the code challenge and code challenge method arguments passed in the first call. The code is later validated in the second call takes the code with the code verifier argument.

## Authorization Code Flow with PKCE in Azure AD

This authorization code flow was recently enabled in Microsoft Azure AD.

Microsoft also released an update of the Microsoft Authentication Library (MSAL) for javascript to support this flow, which is now called msal-browser.

As this library is still in beta, documentation and samples are hard to find. I used one of the Vainila JS starter samples to implement the reusable content provider for React that is shared as part of this article.

The application must be registered as any other regular app in Azure AD under App Registrations, but the the reply url must be set with the type "spa" as it is shown below,

```
"replyUrlsWithType": [
        {
            "url": "http://localhost:3000/",
            "type": "Spa"
        }
    ],
```

http://localhost:3000 is where the React application is running.

## Context Provider Hook in React
In a typical React application, data/state is passed from top/parent to down/children components using properties, but this might not be ideal for cross-cutting corners that apply to all components or state that is shared between all of them. Security is one of those concerns, so it is a good candidate to be implemented as a context provider.

A context provider allows sharing state between components without explicitly passing it as properties through every level of the three. It would be equivalent to a global state that can be accessed on demand by the components.

React provides a hook "useContext" to inject a context with shared state in any component.

Context Provider for Azure AD authentication
The context provider I wrote for this article provides different accessors for state representing the current security context in the applications and functions for user authentication.

```
<MsalContext.Provider
            value={{
                isAuthenticated,
                user,
                token,
                loading,
                popupOpen,
                loginError,
                login,
                logout,
                getToken
            }}
        >
        {children}
</MsalContext.Provider>
```
        
There is a semantic difference between login/getToken and user/token. While login performs user authentication with Open ID/Connect for getting an ID token (the user information), getToken returns an access token for consuming a backend API.

The configuration passed to these two functions (login and getToken) is slightly different. One uses the "openid profile" scopes, and the other uses one scope defined by the specific api to be consumed.

```
// ID token request
export const loginRequest = {
    scopes: ["openid", "profile", "User.Read"],
    forceRefresh: false // Set this to "true" to skip a cached token and go to the server to get a new token
};

// Access token request.
export const apiRequest = {
    scopes: ["api://{API ID}/ReadWrite"],
    forceRefresh: false 
}
};
```

The entry point for using the new msal browser library is the PublicClientApplication object, which receives the configuration for connecting to Azure AD as part of the constructor.

```
export const config = {
    auth: {
        clientId: "{CLIENT ID}",
        authority: 'https://login.microsoftonline.com/{TENANT ID}',
        redirectUri: 'http://localhost:3000/',
    },
    cache: {
        cacheLocation: "localStorage", // This configures where your cache will be stored
        storeAuthStateInCookie: false, // Set this to "true" if you are having issues on IE11 or Edge
  

};
}

const pc = new msal.PublicClientApplication(config);
```

The following component shows how the context provider is imported and used to log in/out the user with two different buttons.

```
const Welcome = () => {
  const { user, logout, getToken, token, loginError } = useMsal();


  return (
    <div>
      <h1>Welcome {user.userName}</h1>
      {token && (<span>Your token is {token}</span>)}
      <br></br>
      <button onClick={() => getToken(apiRequest, "loginPopup")}>Get Token</button>
      <br></br>
      <button onClick={() => logout()}>Log out</button>
      <br></br>
      {loginError && (<span>Error: {loginError.message}</span>)}
    </div>
  );
};


export default Welcome;
```

Full source code for this sample

The full source code for this context provider and sample is available in [Github](https://github.com/pcibraro/msal-browser-react).



﻿



Authorization Code Flow with PKCE

The implicit authorization code flow was initially...

Authorization Code Flow with PKCE in Azure AD with React

# Role Based Authentication for .NET Core APIs with Auth0

Auth0 offers two alternatives for implementing authorization in an API, scopes and roles.

Scopes represent access levels that an API exposes and users can grant to client applications on his/her behalf. For example, "read emails" or "write calendar", which gives a client application permissions to read the user's emails o write the calendar. 

On other hand, roles represent the old school for doing authorization. Users are assigned to roles that represent one or more permissions. Those permissions are passed to the API when the user invokes it through a client application. In Auth0, roles are configured through a feature called [Role Based Access Control] (https://auth0.com/docs/authorization/rbac/) or RBAC in short.

It is worth mentioning that only scopes are mentioned as part of the OAuth 2.0 specification, and roles are usually implemented in proprietary ways by different vendors. As Auth0 uses JWT for representing access tokens, it relies on extension attributes for injecting the permissions for a role into the tokens. We will cover this more in detail later in this post.

For the API, we will use the one included as template with Visual Studio for .NET Core that returns the weather forecast.

## Creating an API in Auth0

First step before jumping into any API implementation is to configure the API in the Auth0 dashboard. 

Go the APIs and click on Create API

![alt](https://photos.collectednotes.com/photos/4455/a891c34e-5581-43fe-aa5c-7d7d88d209a2)

Under the settings tab, configure the following fields.

* **Name**, a friendly name or description for the API. Enter **Weather Forecast API* for this sample.
* **Identifier** or **Audience**, which is a identifier that client application uses to request access tokens for the API. Enter **https://weatherforecast**.
* Under RBAC settings, enable **RBAC** and **Add Permissions** in the Access Tokens**. This will be used by Auth0 to inject the user's permissions into the access tokens.

Under the permissions tab, add a new permission **read-weather** with a description **It allows getting the weather forecast**. This is the permission that Auth0 will inject in the JWT token if the user is member of any of the roles that are allowed to execute that operation. 
  
Finally, click on the Save button to save the changes. At this point, our API is ready to be used from .NET Core.

## Adding a new role in Auth0

Under User & Roles, click on **Create Role** to define a new Role for our API.

![alt](https://photos.collectednotes.com/photos/4455/41dfa958-0738-421c-bf8d-cbbdea02fcbd)

On the **Settings* tab, enter **meteorologist* as role name and description.

On the **Permissions** tab, click on **Add Permissions**, select our  **Weather Forecast API* from the dropdown, and **read-weather** as permission. Click on **Add Permissions*

## Assign the role to existing users

As final step for the API configuration in Auth0, we need to assign the **meteorologist** role to any of the users you will be using for testing the API. If you do not have one yet, you will have to create it and assign it to this role.
Roles are assigned by clicking on the ellipsis button **...** available on each user in the list, and selecting **Assign Roles** option from the displayed menu.

## Anatomy of the JWT access token

If everything is configured correctly, any access token issued by Auth0 for our API should look like the one below,

```json
{
  "iss": "https://....us.auth0.com/",
  "sub": "auth0|...",
  "aud": "https://weatherforecast",
  "iat": 1621346933,
  "exp": 1621354133,
  "azp": "nW5WUNks1eQgHZB0oyc9183NNILpsWMe",
  "scope": "",
  "permissions": [
    "read:weather"
  ]
}
```

> Scopes are not required when requesting an access token for an API configured with RBAC. Only the audience must be passed to Auth0, which is https://weatherforecast in our sample.

## Create the ASP.NET Core API in Visual Studio

Visual Studio ships with a single template for .NET Core APIs. That is **ASP.NET Core Web API** as it is shown in the image below.

![alt](https://photos.collectednotes.com/photos/4455/527a310d-a046-4667-95dd-1a667fa5a7db)

### The structure of the project

Projects created with that template from Visual Studio will have the following structure.

![alt](https://photos.collectednotes.com/photos/4455/85ea61e0-21de-4810-890f-3f5d771ed4e6)

- Controllers, this folder contains the controllers for the API implementation.
- Startups.cs, this is the main class where the ASP.NET Core Middleware classes are configured as well as the dependency injection container.
 
### Configuring the project

Our application will only use a middleware for supporting authentication with JWT as bearer tokens.

Open the Package Manager Console for Nuget in Visual Studio and run the following command.

```
Install-Package Microsoft.AspNetCore.Authentication.JwtBearer
```

Once the Nuget packages are installed in our project, we can go ahead and configure them in the Startup.cs class.

Modify the ConfigureServices method in that class to include the following code.

```csharp
public void ConfigureServices(IServiceCollection services)
{
  var authentication = services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer("Bearer", c =>
    {
       c.Authority = $"https://{Configuration["Auth0:Domain"]}";
       c.TokenValidationParameters = new TokenValidationParameters
       {
         ValidateAudience = true,
         ValidAudiences = Configuration["Auth0:Audience"].Split(";"),
         ValidateIssuer = true,
         ValidIssuer = $"https://{Configuration["Auth0:Domain"]}";
       };
  });

  services.AddControllers();
            
   services.AddSwaggerGen(c =>
   {
     c.SwaggerDoc("v1", new OpenApiInfo { Title = "Api", Version = "v1" });
   });

   services.AddAuthorization(o =>
   {
     o.AddPolicy("read-weather", policy => 
       policy.RequireClaim("permissions", "read:weather"));
    });
}
```
This code performs two things. It configures the JWT middleware to accept access tokens issued by Auth0, and an authorization policy for checking the permissions set on the token. 
The policy checks for a claim or attribute called **permissions** with a value **read:weather**, which is the permission we previously configured for our API in the Auth0 dashboard.
The middleware configuration relies on some settings that we will configure later in the appSettings.json file associated to the application.

Next step is to modify the Configure method to tell ASP.NET Core that we want to use the Authentication And Authorization Middleware. 

Insert the following code as it shown below.

```
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...
  app.UseRouting();
            
  app.UseAuthentication();

  app.UseAuthorization();

...
  app.UseEndpoints(endpoints =>
  {
    endpoints.MapControllers();
  });
}
```

Create a new appSettings.json file and include the settings we got from the Auth0 dashboard before. Those are Domain, and API's Audience.

```
{
  "Logging": {
      "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
      }
    },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "<domain>",
    "Audience": "https://weatherforecast"
  }
}
```

### Require authentication in other controllers
The WeatherForecast controller included in the template allows anonymous calls. We will convert it to require authenticated calls. Fortunately, that is as simple as adding a top level [Authorize] attribute in the class definition. That attribute will also reference the policy we previously defined in the Startup.cs file.

```csharp
[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
  [HttpGet]
  [Authorize("read-weather")]
  public IEnumerable<WeatherForecast> Get()
  {
```

This attribute will do two things,

- It will activate the Authorization Middleware that will check if the call was authenticated and there is one user identity set in the current execution context.
- It will run the **read-weather** policy to make sure the user identity contains the required permissions.

Once we ran this project in Visual Studio, the API will only accept authenticated calls with JWT tokens coming from Auth0.

## Summary

We discussed two of the authorization alternatives available for you in Auth0 when implementing an API in .NET core, and selected **RBAC** for our sample. We also showed how to configure the ASP.NET Core Middleware for Authentication and Authorization, and how to use Authorization Policies for checking permissions on the JWT bearer tokens. 
In a next post, we will see how to implement a client application that negotiates access tokens from Auth0 to consume this API.
  



Auth0 offers two alternatives for implementing authorization in an API, scopes and roles...

Role Based Authentication for .NET Core APIs with Auth0

# Good practices for user authentication in web applications

User authentication is a common concern for almost every web application. If it is not implemented correctly or follows good practices and standards, it can make the web application vulnerable to various attacks, whose sole purpose is to hijack the user session or leak sensitive data. 

## Do not reveal user accounts

A common issue with web forms for recovering user password, or registering new users is that they can reveal if an user account already exists in the system. That represents the first line an attacker can use to determine first if the user account exists, and then try to infer the password with brute force or social engineering attacks.

For the forgot password use case, do not return an error saying the account does not exists if the entered account is not registered in the system. Simply return a generic message such as "The link to recover the password has been sent to the registered email". In that way, an attacker can not find out if the account really exists or not. 

For the user registration scenario, try to use a captcha as part of the registration form. That will prevent someone to run the registration form in an automated fashion or using scripts to determine whether the account exists.  

## Provide multi factor authentication

Multi Factor Authentication (MFA) or also know as Two Factor Authentication refers to a technique that requires an additional authentication factor in addition to a password to gain access to a system. Factor one is something that the user knows, a password, and factor two is something the user owns, such as a unique code sent to a mobile device with an application or SMS or a proprietary device (e.g an RSA token). If the password is compromised, an attacker will still need the second factor to authenticate. 

As proprietary devices (a.k.a hard tokens) are expensive and requires logistics for distribution, second factor is usually implemented through mobile apps that deliver a unique code or token to the user (a.k.a soft tokens). Some examples of mobile apps are Google Authenticator or Auth0 Guardian app.

In the past, second factor was also implemented with SMS, but it was proven after many attacks that SMS is not a reliable solution and it can be impersonated. 

## Provide WebAuthN support

[WebAuthN](https://www.w3.org/TR/webauthn-2/) is the name of a new protocol to support passwordless authentication in web browsers.
The protocol relies on a public key cryptography scheme to generate a private key that is stored somewhere in a safe place on the client side, and a public key that is shared with the server. 
Authentication happens in a form of a handshake between the browser and the server. The browser signs a message with the private key and the server verifies that message with the public key. If the message verification is successful, the user is authenticated. Both the browser and the server must support an API to implement this protocol.
As you can see, this a solution for more sophisticated users. 

[Fido2](https://fidoalliance.org/fido2/) is another specification that relies on WebAuthN to store the private keys in devices protected with a password or PIN. It is another way to support two factor authentication. In order to authenticate in a web application, the user not only needs to have the device but also the PIN or password to unlock the private key on it. Private keys are stored securely on the device and it can not be exported, so it also provides an extra layer of security.

## Limit login attempts

Make sure your authentication form is not susceptible to brute force attacks. Implement a policy to prevent this from happening. That policy can take multiple shapes,

- Block the account after multiple attempts, and notify the user.
- Add a delay that prevents user from being authenticated for a period of time
- Add a captcha for preventing any script for performing the attack in an automated fashion.

If you are implementing authentication through an HTML form, you can also use leverage the CSRF protection mechanism that most web frameworks provide. That will prevent anyone to try submitting the form from an scripting tool.

If you are implementing authentication through API calls from JavaScript, make sure to use API throttling and the same-origin policy enabled. The former will limit the number of calls that can be made to the API in a given period of time by checking the source IP address. The later will prevent the call to be made from an scripting tool.

## Use third party authentication

As last option, if you don't want to deal with all the issues listed above, you can delegate authentication to a third party service like Auth0, Okta or Azure AD.

Those services act as identity brokers that implements the [Federated Identity pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/federated-identity).

You configure your web application to trust any authentication token coming from them. They take care of authenticating users using best practices and standards for authentication. 
These usually support a big variety of authentication or identity providers, so you can easily add support for those in your application with simple configuration.










User authentication is a common concern for almost every web application. If it is no...

Good practices for user authentication in web applications

# El futuro de sistemas de pago esta en Blockchain y Crypto

## Mi primer desafio - Pago Universal

Aun tengo recuerdos de uno de mis primeros proyectos como programador. Fue en el año 2000, unos meses antes del famoso corralito en el gobierno de De La Rua, y para unos de los bancos que luego se disolvieron, La Banca Nazionale Del Lavoro.

El proyecto en cuestion se llamaba Pago Universal, y la idea central era  implementar un gateway de pagos para que cualquier sitio de e-commerce pudiera incorporar pagos con tarjetas de credito y debito Visa, Mastercard y Amex. Para lo que recuerdan, el año 2000 tambien fue el auge de las llamadas punto com. Amazon recien daba sus primeros pasos y otras tantas le seguian el ritmo. Como la historia nos contara luego, no muchas pudieron sobrevivir a esa burbuja de financiamiento excesivo que termino de explotar, pero bueno, eso es otra historia. 

Volviendo a Pago Universal, la premisa era implementar algo similar a lo que hoy es Paypal o MercadoPago a nivel local en Argentina, y en ese momento competia exclusivamente con Decidir, otro portal de pagos de similar caracteristicas.

La division de e-banking a cargo de dicho proyecto en la La Banca era principalmente un Microsoft shop, por lo cual decidieron usar lo que era el caballito de batalla en ese momento, ASP con VB6. Aun no existia .Net, pero Microsoft lo estaba cocinando en secreto para competir con Java.

En ese momento descubri que integrarse con las marcas no era para cualquiera. Mas alla de los desafios tecnicos, habia que tener contactos en el medio, cosa que los directivos del banco tenian. Por otro lado, utilizaban una red propietaria, x.25 si mal no recuerdo. En esa epoca no existia ni XML, web services o ni que hablar Web APIs/REST. Era todo por llamadas RPC usando protocolos propietarios mediante hardware de red especifico.
El banco resolvio esto comprando un producto carisimo de un proveedor en Argentina.
Y por ultimo, se debia pasar por una auditoria de una de esas consultoras gigantes de origen Americano.
El producto salio al mercado, pero no tuvo el exito esperado y creo que termino desapareciendo al tiempo.
Integrarse en forma directa a la red de tarjetas como procesador de pagos tiene una barrera de ingreso grande, y por ende es muy dificil. Supongo que por eso, la oferta de estos servicios es tambien chica, hoy en dia todavia tenemos a Decidir, y MercadoPago entre otros.

## Segunda prueba - Square

Año 2012, doce años despues, una vez que ya me habia independizado y abierto Agilesight con mi socio, en uno de los viajes al campus de Microsoft en Redmond, descubri lo que Jack Dorsey estaba largando en el mercado de los Estados Unidos con Square.
Square introducia algo novedoso, una combinacion de gateway de pagos con un dispositivo que permitia convertir un smartphone en un posnet. Era un pequeño lector de banda magnetica que se conectaba por el jack de audio al telefono, y mediante integracion de software enviaba los datos leidos a la aplicacion de Square.

![alt](https://photos.collectednotes.com/photos/4455/a343113b-07c1-427e-917f-acb905fe2756)

Al volver a Buenos Aires, empece a investigar un poco y descubri que en China ya fabricaban esos dispositivos al por mayor y se vendian a precio relativamente bajo en dolares en Alibaba. Los smartphones con Android ya comenzaban a inundar el mercado y lo vi como una potencial oportunidad para encontrarle una vuelta y alternativa a los tradicionales posnet. Esto se podria utilizar en cualquier lugar que tuviera acceso a una red de datos celular, y sin tener toda la burocracia que implicaba registrarse como comercio o punto de pago en las marcas de tarjeta de credito. 
Compre un par de dispositivos y espere a que llegaran para empezar a desarrollar algo. Aqui comenzo un poco el problema, segundo mandato de Cristina Kirchner, cepo al dolar y las importaciones totalmente bloqueadas. Poder recibir un solo dispositivo me tomo varios meses y un viaje a la aduana. En ese momento, sin antes comenzar nada, ya pense que lograr importar esos dispositivos seria algo imposible, y menos sin ningun contacto conocido o agente aduanero.
De todas formas segui adelante e implemente un MVP (Producto Minimo Viable) en Android para probar la idea y funciono perfecto. La primer parte seria facil. Ahora vendria la segunda parte, comenzar a investigar como integrarse con la red de pagos, y por la experiencia que tenia, era lo mas dificil. 
Envie un par de correos a contactos, y no tuve respuesta. Termine hablando con gente de ventas de Decidir, capaz inicialmente podria simplemente funcionar como interface entre la aplicacion mobile y su gateway de pagos. Grave error, la comision era muy elevada y tambien debia registrar mi empresa como punto de pago. Lo que implicaba que no solo realizaba los pagos, tambien debia actuar como pasamanos de los fondos. Para la marcas de tarjeta, el que realizaba las ventas era mi empresa, no el comercio que utilizaba la aplicacion. Y desde el punto fiscal, mi empresa a pasar a ser una financiera, con lo cual habia que darle un tratado contable especial. Nada de eso de mi agrado por el simple hecho que solo queria probar la idea y ver si funcionaba.

Por meras casualidades, al mismo tiempo me contacta Jose, un ex-compañero de trabajo. El vivia en Cordoba, y tenia un conocido que habia armado una financiera para gente de bajos recursos. Esta persona estaba evaluando expandir su negocio con tarjetas de credito propias, muy similar a lo que habia hecho Tarjeta Naranja, y estaba viendo opciones a los tradicionales posnet pues su negocio se centraba mayormente en vendedores chicos. 

Me hice una escapada a Cordoba en el dia y con un asado mediante, como corresponde, presentamos lo que teniamos.

Mucho no lo convencimos, no le gustaba la idea de depender de un producto importado, y bueno, eso termino quedando en la nada.

MercadoPago finalmente implemento esa solucion pero muchos años despues. Igual no podemos comparar la espalda que tenia Mercado Libre con unos simples mortales.

## El Futuro - Blockchain y Crypto Monedas

Todas las barreras de entrada mencionadas anteriormente en las redes propietarias de las marcas de tarjeta de credito simplemente desaparecieron con la invencion del Blockchain.

En primer lugar, las redes de Blockchain son descentralizadas, y mayormente publicas. Eso implica que no hay servidores centrales en cuales haya que tener permisos para conectarse, y por otro lado, cualquiera puede levantar un nodo para conectarse a las mismas. Por otro lado, son mayormente open source, cualquiera puede acceder al codigo fuente y ver como esta implementado, como asi enviar contribuciones, no mas algo propietario.

Y otra cosa no mejor, al no existir un organizmo central, no estan totalmente reguladas. Y hago incapie en esto ultimo porque mientras existan exchanges en donde uno pueda operar con dinero fiat (emitido por un estado), regulacion siempre va a existir. 

Todo esto y el area de innovacion que hay en este espacio lo hacen ideal para emprender.












 

Mi primer desafio - Pago Universal

Aun tengo recuerdos de uno de mis primeros proy...

El futuro de sistemas de pago esta en Blockchain y Crypto

# Como armar un Arcade con Retropie

Si sos uno de esos que todavia tenes muy buenos recuerdos de la infancia jugando como loco a los fichines en los video juegos, seguramente te habras preguntando como podes hacer para tener una replica de esos viejos arcades en tu casa. 

Gracias a emuladores como Mame y a computadoras como Raspberry PI ahora es posible hacerlo, sin demasiadas complicaciones y a muy bajo costo. 

Para ello se puede utilizar RetroPie, un proyecto muy grande mantenido para la comunidad de desarrolladores para poder utilizar una Raspberry PI como core de una maquina arcade. No es otra cosa mas que una distribucion de Linux totalmente adaptada para facilitar la registracion de emuladores, configuracion de accesorios como joysticks y automatizar el sistema de booteo. 

## Que se va a necesitar para armar el arcade ?

1. Una Raspeberry PI 3
2. Una tarjeta Micro SD de 128GB
3. Un monitor o televisor LCD viejo que no usen. Si tiene entrada HDMI mejor ya que Raspberry solo soporta eso, sino van a tener que conseguir un adaptador de VGA a HDMI
4. Parlantes (opcional si utilizan un televisor con entrada HDMI)
5. Un control SNES USB (Opcional, pero simplifica mucho la configuracion inicial)
6. Un kit de controles arcade Mame USB (Palanca y Botones)
7. Un gabinete de Fibro facil

## Configurar la Raspeberry PI con RetroPie

La distribucion de RetroPie es libre y gratuita. Se puede descargar directamente del [sitio web del proyecto] (https://retropie.org.uk/). Es una imagen que simplemente se restaura en la tarjeta Micro SD (En Windows por ejemplo se puede utilizar Win32 Disk Imager). 
Sin embargo, la distribucion viene vacia, sin emuladores o nada. Uno es responsable de configurar casi todo desde 0 y conseguir los emuladores y ROM. 
El camino mas facil es ir [ArcadePunks] (https://www.arcadepunks.com/retro-pi-downloads-page/) y ya bajarse una imagen totalmente configurada. Cuanto mas pesada la imagen, mas emuladores y ROMs va a tener. 
Por ejemplo, yo utilice la imagen de VIRTUALMAN de 128GB, la cual trae cualquier emulador que se les pueda llegar a ocurrir, desde AMIGA, Atari, Mame hasta SCUM. 
Una vez que se bajan la imagen, la restauran en la memoria Micro SD, y con eso ya estan listos para poder bootear la Raspberry.

## Pruba Inicial

Para el paso inicial, lo mas facil es conectar la Raspberry a nuestro monitor o television y al control SNES. 
RetroPie los va a guiar por toda la configuracion, incluso la deteccion del joystick, y ya estarian listos para probar todos los emuladores

## Como sigo ?

El kit de controles MAME USB que venden tanto aca en la Argentina como en Amazon es una placa con interface USB que hace de intermediario entre el set de botones y la palanca de nuestro arcade. Desde el punto de vista de RetroPie, es simplemente un control USB mas como el cotrol SNES que ya probamos. Se tienen que armar de paciencia, y conectar los botones y palanca a la placa segun diga en las instrucciones/especificaciones. Van a encontrar muchos modelos y marcas, pero la mayoria funcionan de la misma manera, algunos son mas lindos y tienen luces en la botonera.

## El gabinete

El paso final es armar el gabinete, pintarlo o sino plotearlo que es lo mas sencillo. Para ello recomiendo a [Mi Arcade] (https://www.miarcade.com.ar/). Ellos ya te venden todo el gabinete armado en fibro facil y tienen cientos de opciones de plotters para ofrecer. Por otro lado, tienen muchos modelos de gabinete. Fijate cual deberia ser de acuerdo al tamano del monitor, o sino tambien le podes pedir alguno a medida, cobran un extra por eso pero no tienen problema en hacerlo. 

# Resultado Final

![alt](https://photos.collectednotes.com/photos/4455/bc1dce7b-de29-4aad-a2db-c24d018b5609)



Si sos uno de esos que todavia tenes muy buenos recuerdos de la infancia jugando como loco a los fichines en l...

Como armar un Arcade con Retropie

# Check secret expiration for Azure AD Applications using Powershell

When you assign a client ID/secret to an Application Registration in Azure AD, the expiration for that secret is one of the input settings. It could expire in one or two years, or never. 

Bad news is that Microsoft does not provide any support out of the box to notify sys admins when a secret is near to expire, so you have to build that feature for yourself unless no expiration is selected, which is never recommended. 

You can still use the Graph API to query the applications, and check the expiration date for each secret. The following script does exactly that with Powershell.

``` Powershell
param(

    [string]$TenantId,
    [string]$Thumbprint,
    [string]$AppId,
    [bool]$RunAsJob = $false,
    [int]$Days = 30,
    [string]$SmtpUser,
    [string]$SmtpPassword
)

$ErrorActionPreference = "Stop"

$today = (Get-Date).ToUniversalTime()

$limitDate = $today.AddDays($Days)

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

function GenerateJWT (){

    $cert = Get-Item Cert:\LocalMachine\My\$Thumbprint
	
    $hash = $cert.GetCertHash()
    $hashValue = [System.Convert]::ToBase64String($hash) -replace '\+','-' -replace '/','_' -replace '='

    $exp = ([DateTimeOffset](Get-Date).AddHours(1).ToUniversalTime()).ToUnixTimeSeconds()
    $nbf = ([DateTimeOffset](Get-Date).ToUniversalTime()).ToUnixTimeSeconds()

    $jti = New-Guid

    [hashtable]$header = @{alg = "RS256"; typ = "JWT"; x5t=$hashValue}
    [hashtable]$payload = @{aud = "https://login.microsoftonline.com/$TenantId/oauth2/token"; iss = $AppId; sub=$AppId; jti = $jti; exp = $Exp; Nbf= $Nbf}

    $headerjson = $header | ConvertTo-Json -Compress
    $payloadjson = $payload | ConvertTo-Json -Compress
	
    
    $headerjsonbase64 = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($headerjson)).Split('=')[0].Replace('+', '-').Replace('/', '_')
    $payloadjsonbase64 = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($payloadjson)).Split('=')[0].Replace('+', '-').Replace('/', '_')

    $toSign = [System.Text.Encoding]::UTF8.GetBytes($headerjsonbase64 + "." + $payloadjsonbase64)

    $rsa = $cert.PrivateKey -as [System.Security.Cryptography.RSACryptoServiceProvider]

    $signature = [Convert]::ToBase64String($rsa.SignData($toSign,[Security.Cryptography.HashAlgorithmName]::SHA256,[Security.Cryptography.RSASignaturePadding]::Pkcs1)) -replace '\+','-' -replace '/','_' -replace '='

    $token = "$headerjsonbase64.$payloadjsonbase64.$signature"

    return $token
}

if($RunAsJob)
{
    $RequestToken = GenerateJWT
 
    $AccessTokenResponse = Invoke-WebRequest -Method POST -ContentType "application/x-www-form-urlencoded" -Headers @{"accept"="application/json"} -Body "scope=https://graph.microsoft.com/.default&client_id=$AppId&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=$RequestToken&grant_type=client_credentials" -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
    
    $AccessTokenJsonResponse = ConvertFrom-Json $AccessTokenResponse.Content

    $AccessToken = $AccessTokenJsonResponse.access_token
}
else {
    if (!(Get-Module "MSAL.PS")) {
        Import-Module "MSAL.PS"
    }
    
    $TokenResponse = Get-MsalToken -ClientId $AppId `
     -TenantId $TenantId `
     -Interactive `
     -Scopes 'https://graph.microsoft.com/Application.Read.All'

    $AccessToken = $TokenResponse.AccessToken
}

$GraphApiUrl="https://graph.microsoft.com/v1.0/applications";

$headers = @{}

$headers.Add("Accept","application/json")

$headers.Add("content-type","application/json")

$headers.Add("Authorization","bearer $AccessToken")

$GraphApiResponse=Invoke-RestMethod -Uri $GraphApiUrl -Headers $headers -Method GET

$Apps = @()
$Apps+=$GraphApiResponse.value

while($GraphApiResponse.'@odata.nextLink' -ne $null) {
    $GraphApiResponse = Invoke-RestMethod -Uri $GraphApiResponse.'@odata.nextLink' -Headers $headers -Method Get

    $Apps+=$GraphApiResponse.value
}

$ExpiredApps = @()

foreach($App in $Apps) 
{
    
    if($App.passwordCredentials -ne $null)
    {
        foreach($Credential in $App.passwordCredentials) 
        {
            if($Credential.endDateTime) {
                $credentialEndDate = [datetime]::Parse($Credential.endDateTime) 
                if($credentialEndDate -le $limitDate -OR $credentialEndDate -lt $today)
                {
                    $ExpiredApps += @{
                        DisplayName = $App.DisplayName
                        Id = $App.Id
                        AppId = $App.AppId
                        Expiration = ($Credential.endDateTime) 
                        KeyId = $Credential.KeyId
                    }
                }
            }
        }
    }
}

if($ExpiredApps.Count -EQ 0) {
    Write-Output "No Apps found"
}
else {
    Write-Output "Apps that will expire soon"
    Write-Output $ExpiredApps.Count
    Write-Output $ExpiredApps
}
```

You can use that script in any scheduled job and be notified via email about all the client secrets that are near to expire. 

 

When you assign a client ID/secret to an Application Registration in Azure AD...

Check secret expiration for Azure AD Applications using Powershell

# Getting an Access Token from Auth0 in Flutter

Auth0 manages two concepts for representing APIs and Applications (or consumers for those APIs). 
When an access token is negotiated, the client application must present a pair of Client ID and Secret for authentication, and also the identifier of the API is trying to call. 
Auth0 will use the API identifier to include it as audience in the Access Token (JWT) and also apply Role Based Controls (if that option is set for your application).

Before doing anything, you must first register the API and the Application (or Client) in the Auth0 dashboard.  
For an API, the most important setting is the "Identifier".  
For an Application, it is the Domain, Client ID and Client Secret. 

You can use [this article](https://auth0.com/blog/get-started-with-flutter-authentication/) as starting point to configure the development environment for Flutter and the authentication libraries you will need.

The library to be used from Flutter is "flutter\_appauth". You can add it as a dependency under your pubspec.yaml file.

```yaml
dependencies:
  flutter:
    sdk: flutter

  http: ^0.12.1
  flutter_appauth: ^0.9.1
  ....
```

After that, you can simply import the library and use it. 

```dart
import 'package:flutter_appauth/flutter_appauth.dart';

final FlutterAppAuth appAuth = FlutterAppAuth();

const AUTH0_REDIRECT_URI = '<scheme>://login-callback';
```

The Redirect URI configuration in the application is discussed in the article mentioned above.

Finally, you can get an access token using the code below.

```dart
Future<AuthorizationTokenResponse> getApiAccessToken() async {
    final AuthorizationTokenResponse result =
        await appAuth.authorizeAndExchangeCode(
      AuthorizationTokenRequest("<CLIENT_ID>", AUTH0_REDIRECT_URI,
          issuer: 'https://${<AUTH0_DOMAIN>}',
          additionalParameters: {"audience": <API_AUDIENCE>}),
    );

    return result;
  }
```

**CLIENT_ID** is the Client Id assigned by Auth0 to your application when it was created

**AUTH0_DOMAIN** is the Domain assigned to your Tenant in Auth0 (you can also get it from the Application settings)

**API_AUDIENCE** is the Identifier of the API to be called (the one it was defined when the API was registered in the Dashboard). 


 

  

Auth0 manages two concepts for representing APIs and Applications (or consumers for those APIs). 
...

Getting an Access Token from Auth0 in Flutter

# Getting an Access Token interactively for Azure AD from Powershell

Getting an access token under your credentials is very useful in many scenarios for automation, specially when you are writing Powershell scripts. Unfortunately, this scenario is not well documented anywhere by Microsoft. 

I found a Powershell module that wraps MSAL and let you do exactly that. It took me some time to get it working, but here is you can do it.

```powershell
if (!(Get-Module "MSAL.PS")) {
    Import-Module "MSAL.PS"
}

$TokenResponse = Get-MsalToken -ClientId '<Client ID here> `
 -TenantId "<Tenant ID here> `
 -Interactive `
 -Scopes 'https://graph.microsoft.com/User.Read', 'https://graph.microsoft.com/Group.Read.All', 

$AccessToken = $TokenResponse.AccessToken
``` 
You need to get one App Registration created, and assigned with the scopes you will use (Delegated Permissions). The ID for that App Registration is passed as the ClientId argument. 
In the example above, I am referencing some permissions from the Graph API to read the user profiles and groups.


Getting an access token under your credentials is very useful in many scenari...

Getting an Access Token interactively for Azure AD from Powershell

# The state of OAuth 2.0 for Mobile Apps

##Overview
Mobile applications implemented these days for a single native platform such as iOS or Android, or multiple platforms with frameworks like Xamarin, React Native or Flutter, all share the same minimum authentication requirements, which include authenticating users, and also passing authentication data in the form of tokens to external web APIs.

In OAuth 2.0, these requirements are addressed with ID tokens, refresh tokens and access tokens. The purpose of each token will be discussed in following sections.

## OAuth 2.0 Tokens
### ID Tokens
An ID token represents user identity information.  An authorization server returns ID tokens after the user is successfully authenticated (using his username and password for example). In the case of Azure AD, ID Tokens are represented as JSON Web Tokens or JWT. 

JWTs contain three parts, a header with metadata with information about the algorithm and key used to sign the token, a payload with attributes and a signature to make the payload has not been changed in transit.

The payload for an ID token looks as follow,  

```javascript
 {
   "sub": "MCX7TR7RTB5L3YRYR4FIAKX2IE",
   "aud": "dj0yJmk9NDdXZzBEcmJ6UjJxJmQ9WVdrOVlVWktjR0ZLT...",
   "email_verified": true,
   "iss": "https://azure...",
   "name": "Sample user",
   "exp": 1440569876,
   "locale": "en-US",
   "given_name": "sample",
   "iat": 1440566276,
   "family_name": "user",
   "email": "sample.user@mydomain.com"
}
```

ID tokens are only valid for user authentication in the mobile application. The aud attribute in the payload specifies the intended audience for the token. This token should not be used to try accessing external web apis.

###Refresh token
ID tokens have an expiration, which is represented by the exp attribute in the case of JWT. Once the ID token is expired, user should re-authenticate again in theory by providing his authentication credentials (e.g. username and password). The context of the previous sentence implies there are two workarounds for this scenario.

Silent authentication with the use of a hidden iframe. This reuses the existing authentication session on the server side. An additional parameter prompt=none is passed to the Authorization Server so the existing session is reused and the user is not prompted for his credentials.

A refresh token is used instead. Refresh tokens can be renewed indefinitely and does not require an user session to be active on the server side, which make them ideal for scenarios with mobile applications.  

For getting a refresh token with Open ID Connect an additional scope “offline_access” must be passed to the Authorization Server. When this happens, the server will return an ID Token and a Refresh token as well.

For mobile applications, that means the user can be prompted for credentials once, and a refresh token can be used afterwards for renewing ID and Access Tokens until the user explicitly signs out from the application.

###Access Tokens
An access token represents a permission to invoke an external web API. It could be an opaque string that only the web API understands and can validate or a something more self-descripting like JWT. It only targets a single API, and JWT is used to represent it, this target is set in the aud attribute.  The Web API can validate the aud attribute to make sure the token was issued for it by the authorization server, and not any other web api. In that way, the attack surface is reduced once an attacker gains access to a token. 

In the case of Azure AD, an access token can contain one or more scopes, which represent permissions granted by the user on behalf of the client application (for example, an scope for reading the user’s calendar) or roles, which are mapped by Azure AD from AD groups associated to the user. Roles and Scopes can be both used by the Web API to perform authorization.   

```javascript
{
  "aud": "api://myapi",
  "iss": "https://sts.windows.net/tenantid/",
  "iat": 1607435426,
  "nbf": 1607435426,
  "exp": 1607439326,
  "acr": "1",
  "aio": "ATQAy/8RAAAA3L27q98dITMwGbNIBJxxVh7ulCE4rnwBfBT4YsnUUTrcVdn8LivEpzRYI4wg8v2W",
  "amr": [
    "pwd"
  ],
  "appid": "appid",
  "appidacr": "0",
  "family_name": "Test",
  "given_name": "User",
  "name": "Test User",
  "rh": "0.AS0AOme64oK3RE-wtZPakCWCANV2XzQLasFLglhirklcxF8tAOQ.",
  "roles": [
    "Admin"
  ],
  "scp": "read contacts",
  "sub": "jsMTcd0qUKGJRZZ-MBNA3Gaa-iIRoFTEcKV0Ir8sQzQ",
  "tid": "x",
  "unique_name": "test.user@mydomain.com",
  "upn": "test@mydomain.com",
  "uti": "H-XYPjZKVkun3ERouO-XAA",
  "ver": "1.0"
}
```

##OAuth 2.0 Flows
A flow in OAuth represents a process with multiple steps/interactions for obtaining a token.  The specification formalizes various flows that can be used in different contexts or scenarios. To understand where a given flow can be used, the specification also formalizes the types of applications, trusted or untrusted. A trusted app is one that runs in a controlled environment, such a web application hosted in a web server owned by the organization. Different security policies and a firewall can be put in place for this.  An untrusted app is everything else that runs out of the boundaries of the organization, which could be web apps hosted by a vendor, native desktop apps running in personal laptops and mobile apps.

In this context, mobile applications are consider untrusted applications that also suffer from another main problem, client secrets can not be securely stored in these. The application can be decompiled, which will reveal the client secret that is unique for all the users and devices (This is what happened to Twitter in the past). 

To mitigate this issue, the Implicit Flow was considered for many years as the adequate flow for mobile applications. This is not longer true, as the Implicit Flow itself suffers from another issue. It relies on a custom callback from the Authorization Server to retrieve the access token. This callback can be potentially captured in mobile devices by malicious applications or in the case of a web browser, it’s kept in the browser history.

A new extension for the Code Authorization Flow has been introduced, which makes client secrets optional, and the perfect match for Mobile applications and SPA running in a browser.  This extension is called Code Authorization Flow with PKCE.

Implicit Grant Flow will be deprecated in the version of OAuth (2.1)

###Code Authorization Flow with PKCE
This Code Authorization Flow makes use of a Proof Key for Code Exchange (PKCE). It introduces a secret (Code verifier) created by the client application (mobile app or spa) that can be verified by the Authorization Server. 

In addition, this code verifier is transformed by the client in something called Code Challenge and sent to the  Authorization Server via HTTPS to obtain an authorization code. 

If a malicious attacker intercepts that Authorization Code, it can not use it for exchanging an Access Token without the Code Verifier.

How it works.

The user clicks Login within the application.

The client application creates a cryptographically-random code\_verifier and from this generates a code\_challenge.

The client application redirects the user to the Authorization Server (/authorize endpoint) along with the code\_challenge.

The Authorization Server redirects the user to the login and authorization prompt.

The user authenticates using one of the configured login options and may see a consent page listing the permissions the Authorization Server will give to the application.

The Authorization Server stores the code\_challenge and redirects the user back to the application with an authorization code, which is good for one use.

The client application sends this code and the code\_verifier (created in step 2) to the Authorization Server (/oauth/token endpoint).

The Authorization Server verifies the code\_challenge and code\_verifier.

The Authorization Server responds with an ID Token or Access Token (and optionally, a Refresh Token).

Overview

Mobile applications implemented these days for a single native platform such as iOS or Android...

The state of OAuth 2.0 for Mobile Apps

# Auth0 - Enrich ID tokens with custom data

Auth0 uses JWT for representing ID tokens. Those tokens contain a fixed set of standard attributes defined by OpenID Connect (OIDC) protocol such as name, nick_name, or email to name a few.

However, some scenarios might require inject custom attributes to differentiate users and provide different UI experience or functionality.

For example, if you have a multi-tenant platform and you want to group users by tenant in a single Auth0 subscription, the tenant ID could be part of the user profile. This kind of information is usually stored as part of the app_metadata in the user profile as it shouldn't be changed by the user.

Another example is role based authentication. Although this feature is supported in Auth0 for Access Tokens for an API, you might need to know the user's roles in advance to provide different look & feel in the UI. Since the ID token is the first token you get after an user is authenticated, it might also be a good place to inject this information.

Auth0 provides Rules, which represent a programmatic mechanism for injecting that kind of data in an ID or Access token.  

The following rule shows how to inject a Tenant ID into the ID token,

```javascript
function setTenantID(user, context, callback) {

  user.app_metadata = user.app_metadata || {};
  
  let idTokenClaims = context.idToken || {};
  
  idTokenClaims[`https://myapp/tenantid`] = 
    user.app_metadata.tenant_id;
  
  context.idToken = idTokenClaims;

  callback(null, user, context);
}
```

A role can be injected in similar way,

```javascript
function setRoles(user, context, callback) {

  const assignedRoles = (context.authorization || {}).roles;

  let idTokenClaims = context.idToken || {};
  
  idTokenClaims[`https://myapp/role`] = assignedRoles;

  context.idToken = idTokenClaims;
  
  callback(null, user, context);
}
```






Auth0 uses JWT for representing ID tokens. Those tokens contain a fixed set of standard attributes def...

Auth0 - Enrich ID tokens with custom data

Calling Azure Graph API from Powershell with a Client Certificate

The other day ran into scenario with Azure AD that is not very well documented (or documented at all) about calling the Azure Graph API with the client credential flow using a client certificate in Powershell. 

This is only probably needed if you are doing automation work as I was doing for automatically register client or service applications.

When you use client certificates, you don't really pass the certificate but a handcraft JWT that is signed with that cert. This is much more complex as sending a plain text secret, but also more secure as it requires possession of the certificate.

The following script generates the JWT that you will need to negotiate an access token with Azure AD.

``` Powershell
$TenantId = "Your tenant ID"
$AppId = "Your client App ID"

function GenerateJWT (){

    $thumbprint = "your certificate thumbprint here"

    $cert = Get-Item Cert:\LocalMachine\My\$Thumbprint

    $hash = $cert.GetCertHash()
    $hashValue = [System.Convert]::ToBase64String($hash) -replace '\+','-' -replace '/','_' -replace '='

    $exp = ([DateTimeOffset](Get-Date).AddHours(1).ToUniversalTime()).ToUnixTimeSeconds()
    $nbf = ([DateTimeOffset](Get-Date).ToUniversalTime()).ToUnixTimeSeconds()

$jti = New-Guid
    [hashtable]$header = @{alg = "RS256"; typ = "JWT"; x5t=$hashValue}
    [hashtable]$payload = @{aud = "https://login.microsoftonline.com/$TenantId/oauth2/token"; iss = "$AppId"; sub="$AppId"; jti = "$jti"; exp = $Exp; Nbf= $Nbf}

    $headerjson = $header | ConvertTo-Json -Compress
    $payloadjson = $payload | ConvertTo-Json -Compress
    
    $headerjsonbase64 = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($headerjson)).Split('=')[0].Replace('+', '-').Replace('/', '_')
    $payloadjsonbase64 = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($payloadjson)).Split('=')[0].Replace('+', '-').Replace('/', '_')

    $toSign = [System.Text.Encoding]::UTF8.GetBytes($headerjsonbase64 + "." + $payloadjsonbase64)

    $rsa = $cert.PrivateKey -as [System.Security.Cryptography.RSACryptoServiceProvider]

    $signature = [Convert]::ToBase64String($rsa.SignData($toSign,[Security.Cryptography.HashAlgorithmName]::SHA256,[Security.Cryptography.RSASignaturePadding]::Pkcs1)) -replace '\+','-' -replace '/','_' -replace '='

    $token = "$headerjsonbase64.$payloadjsonbase64.$signature"

    return $token
}
```
You will have to replace the TenantId, AppId (The client app where the client certificate was previously registered in Azure AD), and the client certificate thumbprint. 

Once the JWT is generated, it can be used to get an access token for the graph api using the script below.

```Powershell

$RequestToken = GenerateJWT

$AccessTokenResponse = Invoke-WebRequest `
       -Method POST `
        -ContentType "application/x-www-form-urlencoded" `
        -Headers @{"accept"="application/json"} `
        -Body "scope=https://graph.microsoft.com/.default&client_id=$AppId&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=$RequestToken&grant_type=client_credentials" `
        -Verbose `
        "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" 
    
$AccessTokenJsonResponse = ConvertFrom-Json $AccessTokenResponse.Content
$AccessToken = $AccessTokenJsonResponse.access_token
```

*Import Note*. If you use a self-signed certificate, don't use one generated with Powershell as the private key will not be accessible. Try using a certificate generated with openssh.






