Authentication : Permissions
Updated: Aug 21, 2019
First question. What is a permission?
Great question anonymous reader!
A permission simply means: you I do blah, to this resource. A permission is a string that is contained in a token and it defines a/ set of particular CRUD (Create, Read, Update, Delete) command(s). Permissions can come in all shapes and sizes. They do generally fall into to one of two categories:
. User Consented
. ADMIN Consented
User permission are by far and away the most commonly used of the two (from what I have seen). Simply put they mean: does the user let me do X? Can I read the user's [insert resource]. Or can I delete the user's entire [insert resource]. These types of permissions require user consent, before they can be attached to a token. As such they can only be acquired on the front end. They also involve having to redirect the user to a specific uri to obtain and use the token. Generally speaking user permissions only let you preform CRUD commands on resources that the user can access.
Ah yes, the dreaded ADMIN permissions. These are very unrestricted. As in anyone can use them to do anything that they are permitted to do. You need to be very careful when you require these. Examples of these include, removing a user, creating a new object in the company's account, etc. The admin must consent to these for them to be used. With these permissions the user is taken out of it, and they can be attached to the users token. Tokens that require these permissions can be acquired on the back end by using a service account, or an auth apps credentials (client Id, client secret).
Later on (hopefully) we will be looking at these permissions for an auth app that we will create for a function app.
I have left a link if you need further reading material: