In part one we saw how a busy server center manages customers using tokens.

But we only encountered good people which unfortunately is not the case in the real world. Now bad actors come into the picture.

• People trying to steal the token

• People trying to view the token code and use it.

• People creating a fake service center and stealing money in the name of paid service.

• People creating fake token issue counters.

In security terms, it's called an attack vector. You need to make sure your API has the least number of or ideally no attack vectors.

Now the service center's challenge is to make sure the customer doesn't fall in any of these traps.

Will the service center be able to protect itself from these attacks?

The first thing the service center does is to make it impossible to create a fake service center or a token issue counter. It displays a certificate that must be verified by the customer before carrying out any transaction. This unique certificate cannot be duplicated.

In Oauth 2.0 this is done with the help of Public/ Private keys. The Authorization server generates these keys and provides the client ( Your API ) public key for verification. When you connect to the server it will return a signed message which verifies the identity of the server. No other server can present the same signed message.

To avoid token stealing or unauthorized viewing the service center must ensure that its premises are secured and no unauthorized person can view or attach a camera where the token is being issued. For this, the service center creates a guarded premise with strict entry.

Similarly in Oauth 2.0, the communication channel between the Authorization server and the client is secure to ensure nobody can see or steal the token. This is done by using SSL which ensures that the communication channel is secure and tamper-proof.

The server will verify the client similarly with Public/ Private keys. It's important to note that the private keys of both server and App are secure as they are only used for message signing and never travel on communication channels.

Now the question in Part One is, what will happen if the Access token gets leaked?

In that case, the holder of the token will have full access to the scope in short you are hacked.

This can happen if you manually provide an access token e.g by sending your screenshot of the access token to some person.

The good news is that Oauth 2.0 mandates the access token to be of a very short duration e.g. 30 mins so the attack is limited to 30 min and after that duration, the new access token will be required with the help of a refresh token. Compare this to that with a user/password authentication where if the password is compromised the account becomes vulnerable until the password is changed.

This was an example of the web flow of Oauth 2.0.

Now the Service center can carry out its business without worrying about the Villains. But what will happen if the customer is unable to come and take a token from the issue counter and wants a token by phone?

Oauth 2.0 has use cases for authentication from

• Mobile.

• Command Line.

• TV.

• Washing Machine.

Can this be explained from the service center example?

Follow this Blog for updates.