In today's post we continue our discussion on how an OTP provider can replace the tokens used by an API for checking authorization. In this case, the we will call it an OTT provider. An OTT provider converts all users/ digests/sessions/cookies  to track users into tokens. A TOTP 6 digit number as usually provided by OTP  providers. These tokens not only replace the credentials but also serve to maintain sessions. With the API only accepting tokens, there is no need to track anything else. In a way there is no repository required fro the API implementations to see if there is a token associated with a user or a client. The token itself has both pieces - 'what you know' and 'what you have' and the API implementation can validate the token the same way as when the caller did after requesting it.
There are only three players:
A token provider that issues and validates token
An API client that requests tokens from the token provider and validates it
An API server that accepts only tokens and validates it from the same token provider.
Tamper proofing the request or encrypting the transport layer is not part of this discussion but considered necessary.
Although the OTT is enclosed with the request and sent over the wire, it is temporary and gives the api what is needed.
OTP is covered in RFC 2289 which states that there are two entities in the operation of the OneTimePassword system. The generator must produce the appropriate one-time password from the user's secret pass phrase,  and from the information provided in the challenge from the server. The server must send a challenge that includes the appropriate generation parameters to the generator, must verify the one time password received, must store the last one time password it received, and must store the corresponding one-time password sequence number. The server must also facilitate the changing of the users' secret passphrase in a secure manner.
Int GetDistinctMean (int [] A)
{

if (A == null) return 0;

return A.GetDistinctMean ();

}