Authentication Strategies
By: Johnathon Wright on: January 30, 2017
Just thinking about all the possible authentication strategies and tokens:
Single Auth Token
As a user, I want to authenticate for a single request, no session or authentication persistence, for API purposes or downloads. I assume it was a thing before this, but I was introduced to it by AuthLogic, long may it reign.
Looks like:
POST domain.test/invoices.xml?token=sometokenhere
or
GET domain.test/reports/65432.pdf?token=sometokenhere
Instance-based key
As a user, I want to be able to send a link to a non-user so that they can look at just this one page without having to authenticate because I know they should have access to this one piece of information.
Looks like:
GET domain.test/reports/65432.pdf?key=sometokenhere
- You wouldn't want to use the same param as for auth-based
- You can either store a key OR you can derive one based on some set of fields. Note that in the first case, you can reset the token if it becomes exposed. In the second case, you gain simplicity. Each case must be judged on its own merits.
Here's an example of generating a token based on some input:
def token(seed)
sha256 = Digest::SHA256.new
digest = sha256.digest(seed.to_s + SOME_SECRET_CONSTANT)
return Digest.hexencode(digest)[0..10]
end
Perishable Token
As a user, I want to authenticate and create a session using a token that expires when used OR after some short lifespan so that I can reset passwords.
This idea also came to me through AuthLogic, long may it reign.
One tricky thing about perishable tokens. You need them to create a session because you're going to (a) show a form and (b) change the password. But some developers might want the user to have to login after resetting the password, and wouldn't want them to see a menu that would allow them to not reset their password. So you have to add some extra logic around being partially authenticated, or allow the perishable token to live past its first use. So that's weird.
In the past I've put this token on the user. But I'm starting to think it belongs in its own table now.
perishable_tokens table:
- key
- user_id
- created_at - datetime
- expires_at - datetime
- used_at - datetime
- rescinded_at - datetime - an administrator may choose to rescind one or all open tokens
This way you keep a history of attempts, which may be interesting in terms of finding patterns if you suspect some kind of And obviously if expiresat is in the past or usedat is not NULL, it isn't valid. And you might want some validation around not having more than one per user.
Link-Through Authentication
As a lazy user, I want a link in an email to log me in automatically.
Everyone is booing. I hear you. I know, it flies in the face of web security. Banks should avoid this. But I saw it being done by Motley Fool and I think it's a good fit for their audience. Probably older. Probably not tech savvy.
I don't mind it. If you own the email address you own the account, so who cares.
One thing is how long these links should live. Fool.com sends you a one-use link. But there are some very-low-security sites for which auth-until-password-reset might be ok!
Any others?