When we talk about access control in modern applications, one term you’ll often hear is delegated permissions. At first glance, it might sound like technical jargon, but the idea is simple: you allow an application to act on behalf of a user, but only within the limits the user has agreed to.
Think of it this way: imagine you give your assistant the keys to your office so they can pick up documents for you. They can enter the office, but they can’t use those keys to walk into the CEO’s cabin or access other restricted areas. The permission you delegated is specific, temporary, and tied to your authority.
Why Delegated Permissions Matter
Delegated permissions strike a balance between convenience and security:
User control – The user decides what an application can or cannot do.
Least privilege – Apps don’t get unrestricted access; they only do what the user allows.
Better user experience – Instead of constantly asking for credentials, apps can act on behalf of users once consent is given.
This model is at the heart of how services like Microsoft Graph, Google APIs, and OAuth 2.0 integrations work.
Example 1. Email Access via Microsoft Graph
Suppose you’re building a productivity app that integrates with Microsoft 365. A user signs in with their work account and grants your app delegated permission to read their emails.
Here’s what happens:
The app receives a token that represents the user.
With that token, the app can call the Microsoft Graph API to fetch emails.
But it can only fetch that user’s emails, not their colleagues’ messages.
If tomorrow the same user revokes permission, your app instantly loses access. That’s the “delegated” nature of it — your app is borrowing their access rights, nothing more.
Example 2. Calendar Integration with Google
Think of scheduling apps like Calendly. When you connect your Google Calendar, the app asks for delegated permissions to create events.
This doesn’t give Calendly blanket access to Google services. It can’t delete your Drive files, check your Gmail inbox, or mess with your contacts. It can only insert and update events in the calendar you allowed it to use.
Delegated vs Application Permissions
A lot of confusion comes from comparing delegated permissions with application permissions.
Delegated permissions: The app acts on behalf of a user (requires a signed-in user). Example: reading your emails after you log in.
Application permissions: The app acts on its own, with full system-level access (no user required). Example: a background service that syncs every employee’s mailbox in a company.
Common Pitfalls Developers Face
Over-requesting permissions – Asking for more than necessary frustrates users and raises security concerns.
Not refreshing tokens – Delegated tokens expire, so apps must handle token refresh gracefully.
Ignoring revocation – If users withdraw consent, your app must stop making API calls on their behalf.
Final Thoughts
Delegated permissions are about trust, scope, and balance. They give apps the power to do useful work without handing over the keys to the entire system.
As developers, we need to design our apps in a way that respects these boundaries: ask only for what’s needed, explain clearly why, and honor the user’s control at every step.
The next time you log into an app and see a screen saying, “This app would like to access your calendar”, you’ll know you’re dealing with delegated permissions in action.
Join the conversation! Your thoughts help the community grow.