Mold an amateur's API authentication approach

Jan — Thu, 30 Aug 2018 03:55:38 +0000

The process

I know and I am familiar that we have oauth/oauth2 advancements in the API authentication area but I can't help but explore my own ideas on it.

I have this idea for API authentication. Simple and straight to the point. But I can't help but feel that I lack a few more scenarios to consider on designing this flow.

Glossary/Legend :
Token = unique combination of string
User = Registered entity in the project/app
Red boxes = Process that would induce a "SELECT" clause
Blue boxes = "UPDATE" clause
Green boxes = "INSERT" clause

So to start, the User makes a request to the API to create a token, the API then checks the token table if there are existing ones tagged to the user that are not yet expired, if a token exists, the expiration will be increased and returned to the user, if none a new token is created and returned.

After successfully securing a token, the user is now able to request for resources from the API.

Now for EVERY resource request the user makes to the API, the request would only need to include the token (aside from the parameters of the resource requested) and the can already determine which user sent the request, the API will then check the validity and expiration of said token in the database, if token is valid, return the resource, if not return a 401 http code.

Additional notes : Thinking about 3rd party logins, Some sort of access type can be attached to the token to determine the purpose of it, i.e. access via facebook, twitter etc

I believe in this logic but I wanna find out things that would make this a more better and industry-standardized approach so to speak.

Cheers!

Forem: Jan

Mold an amateur's API authentication approach