Revoking access
Where to revoke access, what happens to the application afterwards, why an application keeps asking for authorization, and how revocation differs from signing out.
How to revoke an application's access
Open authorized applications in account settings to see everything you have authorized and revoke them one by one.
What happens after revoking
| Object | Result |
|---|---|
| Access token | Invalid immediately; subsequent requests return 401 |
| Refresh token | Invalidated too, so the app cannot silently renew |
| Grant record | Deleted; the app must go through the consent page again |
| Your signed-in state in that app | Usually ends as well, requiring a new sign-in |
Why does an application keep asking for authorization
Three common cases:
- A new device — grants are kept per client and per device; a new device needs its own confirmation;
- You revoked before — revocation deletes the record, so the next visit naturally asks again;
- The application asked again — it wants more scopes, or re-initiates after detecting an invalid token.
How is revocation different from signing out
| Action | Scope of effect |
|---|---|
| Revoking an application's access | That app loses the right to read your data; your MuoCeon session is unaffected |
| Signing out | Ends the session on your current device; authorized applications keep their access |
They do not substitute for each other: revoke access when worried about an application, revoke sessions when worried about a device being used by someone else.
Related
- Sessions and devices: Sessions and devices
- How revocation behaves on the wire: Endpoint index
Consent page and permissions
Why the consent page appears, what each permission actually means, what happens if you allow only part of it, and when consent takes effect.
Integration and debugging
Developer-side FAQ — registering a client, redirect URIs, code exchange, refresh and validation, grouped by integration stage.