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!
Top comments (1)
I think this is how tokens are meant to work already. Don't think you can make it much better other than looking out for possible injection points, what kind of data users are allowed to request (maybe some can more than others to facilitate different needs?), and for the token to be unique.
I don't see how/why it would need to be more complicated than that. Nice diagram by the way!