In our previous article we walked you through how to create a registration API in 15 minutes. Once we've got registrations, the only thing missing is the ability to login, or authenticate, and we've gone full circle in regards to everything related to registrations and authentication.
In the video below I walk you through this part in roughly 4 minutes.
The code
The code for authenticating is of course much simpler than the code for registering, since it doesn't imply sending emails, validating input, etc. Below is the complete code required to authenticating a user towards your cloudlet.
login.get.hl
/*
* Authenticates the user towards the cloudlet
*
* Very cool app!!
*/
.arguments
username:string
password:string
/*
* Authenticates the user with the specified [username] and [password].
*
* Returns a JWT Bearer token that can be used for consecutive requests authorizing user according
* to his or her roles.
*/
execute:magic.workflows.actions.execute
name:authenticate
filename:/modules/registration/workflows/actions/authenticate.hl
arguments
username:x:@.arguments/*/username
password:x:@.arguments/*/password
// Returns the result of your last action.
return-nodes:x:@execute/*
The above code creates an HTTP GET endpoint taking username and password, then it invokes the "authenticate" action, for then to finally return the result of this action to the caller. Invoking the API results in a valid JWT token you can associate with future HTTP requests as a JWT Bearer token, which will automatically allow you to create authorization logic on your endpoints using RBAC.
About RBAC
RBAC is an acronym and implies "Role Based Access Control", and is the foundation of almost everything we do related to security. RBAC allows you to associate access to some resource with some "role", for then to associate users with that role, only allowing users associated with your role to access the resource or perform some action.
In our previous article we created double opt in logic, that only added the user to the "guest" role as they confirmed their email address. This implies we've got a guarantee of that nobody belongs to the guest role unless they've verified their email address. This creates some basic accountability since no user can invoke a "protected" API endpoint unless they've actually verified their email address. This is probably the most common registration pattern in the world today, something you can clearly see if you register at any website or webapp out there.
RBAC is an easily understood mechanism to implement such accountability and authorization requirements.
About JWT
JWT is another acronym and implies "JSON Web Token". It's based upon three core web standards; JSON, base64 encoding, and cryptographic hashing.
A JWT token contains 3 elements, something you can see by the fact of that it has 3 parts, separating each part with a ".". The first part is the header and informs the recipient of what hash was being used. The second part is its "payload" or content if you wish. The third part is a cryptographic hash created by hashing the payload. Since the hash is created by concatenating a "secret" to the payload before the hash is created, this ensures only those with access to this secret can re-create the hash. It also easily allows anyone knowing this secret to verify the token was created by someone who knows this secret.
This allows us to transfer the token to consecutive requests towards our backend as an HTTP "Bearer" token, in our requests' HTTP Authorization header. When a request with a Bearer token is received on the server, the server just needs to verify the hash or the token's "signature" was created by somebody who had the correct secret.
When you create a cloudlet at AINIRO.IO, we use CSRNG to create a pseudo random secret that's roughly 100 characters in length. This creates a highly secure solution for securing your API endpoints, making your authorization logic almost impossible to crack, assuming you can keep your token secure in your client application. You can read more about JWT below.
Conclusion
We've now got registrations, RBAC, accountability, confirming emails, and login. In our next articles we will take a look at how we can start building our actual app - However, so far we've spent 19 minutes in total. 15 minutes to create our registration API, and 4 minutes to implement authentication. Not too bad if you ask me.
If you wish you can at this point implement logging in your login endpoints, and/or your registration endpoint(s). However, that's an exercise for you. If you want to do this, you should check out the "log" action in your toolbox.
Notice, I want to emphasise that even though we've only spent 19 minutes in total, this is production quality code. If you started out with anything but magic, you would need weeks, maybe months to create the same functionality.
Top comments (0)