--Originally published at Ce qui est chouette
In this post I’ll be dealing with the topic of Authentication and Authorization, and at the end of this post I’ll provide some examples and summarize some of the currently used solutions.
The difference
First, let’s deal with what both of these concepts refer to and what the difference between them is.
Authentication means verifying who someone is. This is what sign up and log in are for, the first one defines who you are, while the latter is where the authentication lies, in checking your user-id and password to match you with someone in the system; authentication answers the claim this is who I am with a yep, that’s who you are.
Authorization means verifying that someone has permission to perform an action. This refers to a certain user having or gaining access to a resource, this is usually done through the use of different types of user, e.g., Administrator, Anonymous User, etc; authorizations answers hey can I do this? with yep, you can or if it were an english teacher, can you? to which you would simply groan in disgust at this attempt at comedy.
Tokens
One common way to handle both these processes is through the use of tokens. A token is a series of characters, usually encoded, that represent both to whom the token belongs—to which account it is linked—and what type of access this token has.
An implementation of tokens that I’ve used is JWT (JSON Web Token). JWT consists in three parts: header, payload, and signature. The first two are all base64 encoded and separated by a dot (.), the signature is a bit different, it consists in the following:
EncryptionAlgorithm(base64( HEADER ) + "." + base64( PAYLOAD ), SECRET)
The signature part of a JWT consists in taking concatenation of the previous parts, both base64 encoded and separated by a dot, and encrypting and signing it with a SECRET key. As you may have guessed, JWT isn’t supposed to protect your payload from eavesdroppers, what it does is prove that a JWT was emitted by an entity within the system, because of that SECRET key that’s used to sign the signature part of the JWT. Because JWT still exposes user data, it is advised to not include something confidential inside them, what you may include in a JWT is:
- Who this token represents—subject claim, user.
- Who issued this JWT—issuer claim, client application.
- Who this JWT is meant for—audience claim, the server that’s meant to read it.
- Up to when the token is valid—expires claim, the Unix Epoch up to which the JWT is valid, or, just if issued at is also provided, the time, in seconds, during which it is valid.
- When this token was issued—issued at claim, the Unix Epoch.
- Custom claims that don’t compromise confidential information, like level of access this token has.
JWTs should be used when a secure connection can be established, so as to not expose this data the public, just in case. As to where to store them I’ll link an article that explores that topic, as its another beast on its own: Where to Store your JWTs – Cookies vs HTML5 Web Storage.
– I swear its me.
