Server-Side
This section describes important security recommendations and best-practices for the server side.
Main Risks on the server side
Insufficient validation of tokens (Opaque tokens or JWT)
Replay of stolen tokens on multiple resource servers
You always have to make sure to validate all tokens you get sent from clients to the server side before using these. In case of opaque tokens you must validate these using the token introspection endpoint. In case of JWT you have to validate at least the signature and the expiry date/time. In production systems you must use signed JSON Web Tokens (JWT) in all times. In test systems you may use unsigned tokens for to make testing easier but please make sure that these test tokens are really denied on production. In earlier times there have been some libraries that could be tricked to ignore the signature of a token if the header has been altered to signal an unsigned token. Luckily today the libraries always deny such tokens that have a signature but have such a false header set.
To restrict tokens from being used everywhere it is also recommended to use the audience claim to restrict a token for only some backend APIs. So, it a token gets stolen, the attack surface can be reduced by such an improvement.
Best Practices and Recommendations
Always validate the access token on the server side (at least the signature and expiry date/time). It is recommended to check the audience claim as well.
Keep lifetime short for access tokens (especially when these are stored in the browser), 5-30 minutes are OK
Always use a proven library for all that OAuth2 and OpenID Connect token validation stuff (you find a good library for almost every kind of programming language). Please check the OpenID Connect certified implementations.
You can find even more recommendations and best-practices here at the IETF:
Last updated