The common work of the back end is to provide serial connection through various APIS on corresponding products, which may be browsers or mobile phones. In addition, with the rise of MicroService, the connection between Server and Server is also a common way of communication.

When services use APIS to communicate, common apis may require authentication or authorization to obtain permission to use, unless public apis do not require authentication.

API Token authentication method design

The following is a brief introduction to the design features and advantages and disadvantages of common API Token concatenation, so as to provide a quick clarification in the design:

  • Design your own Token
  • JWT Token
  • The 2.0 validation

Design your own Token

  • Application scenario: Home-server service interconnection, that is, callers are home-server services or servers
  • advantages:
    • Practical simple
  • disadvantages:
    • Hardcode must be set
    • To update the Token, both the Client and Server must be manually updated
  • Remark:
    • If multiple groups of clients can access the tokens, separate the tokens. If one group of tokens needs to be set to invalid, the tokens of other groups can continue to be valid

JWT Token

  • Applicable situation:
    • Need to be the originator for personal identification
    • MicroService Server or Client Side services are connected
    • Use of single authentication behavior (e.g. Email authentication)
  • advantages:
    • Customized distribution based on a single identity or act
    • You need to entrainment (non-sensitive) information for use
    • Set an Expired time to reduce the risk of Token loss
  • disadvantages:
    • After the Token is sent, it cannot be recalled. You can only wait for the Token to expire or create a blacklist mechanism on the Server to Block the Token
    • To update the Token, both the Client and Server must be manually updated
  • Remark:
    • Note whether the encoding length exceeds the JS cookie or Local Storage length
    • Regardless of CSRF attack prevention, as long as JS can Work, there is a chance that Token can be stolen to cause an attack
    • See my previous introduction of deep ink JWT

The 2.0 validation

  • Advantages:

    • In contrast toSelf-designed Token interconnectionAs well asJWT TokenDocking provides greater managerial flexibility,
    • You can set scopes and access data ranges

  • Disadvantages:

    • The process is tedious and rigorous

  • Note: Different types of Grant have different situations, as outlined below:

Request Grant profile

❖ Authorization Code Grant

  • Applicable situation:
    • Client credentials, e.g. client secret, refresh token can be saved
    • Third-party apps such as Server Side Web apps that are not seen by others
  • OAuth2 providers are almost implemented by Google, FB and Amazon

❖ Implicit Grant

  • Applicable situation:
    • Client Secret third-party apps such as Mobile/Desktop APP and JavaScript Web APP cannot be saved

❖ Client Credentials Grant

  • Applicable situation:
    • A scenario in which the OAuth2 Client obtains Authorization directly from the Authorization Server.
    • The OAuth2 Client is itself the Resource Owner.

❖ Resource Owner Password Credentials Grant

  • This authorization process requires the user to enter the account secret, so it is generally not open to the OAuth2 Client of external developers to avoid the risk of the user’s account secret being recorded by a third party.
  • Applicable situation:
    • It applies to self-developed apps such as Mobile/Desktop APP