#secure JWT talk
##Security concerns
- Prevent malicous code from executing in client
- still be able to provide user access info
###MITM attack solve with
- https everywhere
- tls locally
- secure flag on cookies
###xss solve using
- server side and client side escaping
- using https-only cookies
###csrf
- attacker puts malicous requests on webpage
to solve
- synchroniser token
- double-submit cookie (x-xsrf-token)
- origin header check
####cors stuff Do not use wildcards on allow origin stuff. whitelist sites during development
##Token auth large string in 3 parts
- header
- body - important
- iss = who issued token
- exp = when expires
- sub = who is represented
- scope = what they can do
- cryptographic sig
tokens issued by server, signed with secret key
- dont use local storage (can be used in xss)
- use http-only secure cookies to store access tokens
###verification Implicitly trusted because cryptographically signed - stateless
###jwt + Oauth2 rfc 6749
- 2 tokens
- access token - short lifetime. Used to allow access to the server
- refresh token - long lifetime, can be used to refresh the access token. used to sanity check the user (i.e are they banned? How often the refresh is required can be controlled by the server)
auth logic would be to check access token 1st (sig and expiry), then if its not valid try to get new access using refresh token. if this doesnt work delete token.