August 6th, 2017
6:19 pm
Posted under Web
Permalink
Tags Tip, Tutorial
Lots of pros and cons re this – not to mention flame wars online!
The basics:-
- A digitally signed token with a header, a payload of ‘claims’ or assertions, e.g. ‘I’m a superuser’, and a digital signature.
- The digital signing allows a server to confirm both that the token is ‘one I prepared earlier’, i.e. one of it’s own, but crucially also that ‘the content e.g. the claims have not been modified’
- In theory and on the face of it this allows a server to be stateless and avoids the need for session state/sticky sessions and the like – the session state can be passed in the JWT to the client.
- There are problems – one is access revocation. If the server decides ‘I am going to cancel your session now because I doubt your security’ it has no way of revoking previously created tokens. A stateless server would continue to honour an old token.
- A revocation list can help a server to address this – a list of JWTs that it knows are revoked. However we are now back to server side state again, albeit less of it.
- A server can change its digital signing key to obviate this but this would invalidate every single JWT, not just a single one.
- However, a valid technique could be for the server to mandate token reissue periodically, i.e. change its digital signing and require clients to poll the server to refresh their tokens. However the server would still need to perform some kind of revocation check on token reissue.
- If a JWT can be stolen then anyone can reuse it. Issues such as Cross Site Request Forgery can be an issue, see also here. Where you store your JWTs client side is important, e.g. local storage vs cookies.
This post argues strongly that JWTs are not suitable as a server side session substitute. A number of the points seem overly opinionated and not entirely balanced, but it does make a number of good points.
This google docs page gives a more balanced comparison chart of a number of API authentication techniques and is worth a read.