Authentication with JSON Web Token (JWT)

JSON Web Tokens are the preferred approach as it provides fined grained access control to the suite of REST APIs. An administrator creates a JWT with specific access rights and then provides it to the appropriate resource such as a developer, IT, contractor, etc. A common scenario is to create a separate JWT for every developer that needs access to the REST APIs and then create additional (production) JWTs that are used by applications / services in production.

JWT Advantages:

• Every developer has their own JWT 
• Every JWT has an expiration date/time from seconds to years
• A JWT can be revoked at any time (even before it expires)
• Each JWT has a set of fine grained access permissions
• Permissions can be assigned / removed from an existing JWT with requiring the JWT be be recreated
• JWT can be created for extending access to third parties / consultants

Authentication with customerid and customercode 

The old way of accessing the REST APIs is by using a unique developer token. This is an often employed practice by many software vendors. In ServiceMobility the developer token consists of two parts, the customerid which was a fixed value that never changed and a customercode. The customercode value (which can be thought of as a password) could be change by the customer at any time. To access the REST APIs, the customerid and customercode values are passed as URI parameters to every API call.

While this approach is very easy to use, it does present a number of concerns and are the reasons why ServicePower recommends using JWTs to access the REST APIs. 

Concerns:

• It provides full administrator access to all of the REST APIs
• A single access code is used by all developers and application making true auditing more difficult
• If the code has to be changed it effects every developer and application
• You would not want to provide the customercode to third parties or external consultants