Token Based Authentication

Token Based Authentication


In the previous exercise, we had to
sent the username and password with every request that was protected by
the off.loginrequired_decorator. This is inconvenient and can be seen as a security risk even
if the transport is secure HTTP. Since the client application must
have those credentials stored without encryption to be able to send
them with these requests. When rendering HTML pages with Flask, we
had the ability to use the login session object to store information about the
state of the client between requests. Flask did this by creating
an encrypted cookie for us that the browser could
append to each HTTP request. But since our RESTful API may not
always work with the browser or a client that can securely store and
transmit cookies, we need another method for storing and
communicating credentials. A popular solution to this
problem is to create tokens. A token is a string that
the server generates for the client that can be passed
along inside an HTTP request. The idea is that the client application
exchanges authentication credentials for an authentication token and in subsequent requests,
just sends the token. When the server receives the token, it can then look up the credentials
of the user and determine whether or not it is authorized to
the information it is requesting. Tokens are usually given out with an
expiration time after which they become invalid and
a new token needs to be obtained. The potential damage that can be caused
if a token is leaked is much smaller due to their short life span. A server can easily determine if a token
is to old and decide to reject it, if it doesn’t view it as valid. So how would we go
about creating tokens? A straight forward implementation
is to generate a random sequence of characters of certain length
that is stored with the user and the password in the database. Possibly with an expiration date,
as well. The token then becomes sort of a plain
text password in that it can easily be verified with the string comparison
plus a check of its expiration date. A more elaborate implementation that
requires no server side storage is to use a cryptographically
signed message as a token. This has the advantage that
the information related to the token namely the user for which the token was
generated is encoded in the token itself and protected against tampering with
a strong cryptographic signature. Flask uses a similar approach
to write secure cookies. This implementation is based on
a package called itsdangerous. In the next video,
we will use the itsdangerous library as we take on adding token generation
and verification to our user model.

Danny Hutson

12 thoughts on “Token Based Authentication

  1. 1:18 why is the potential damage smaller due to the "small" lifetime of tokens? To an army of computers, even as little as 1 minute can be a very long time to do damage…

Leave a Reply

Your email address will not be published. Required fields are marked *