You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 71123ad
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/content/client-sdk/authorization.md
+78Lines changed: 78 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -164,6 +164,44 @@ A wildcard is not a substitute for satisfying independent security policies, aut
164
164
165
165
## 4. Check Authorization
166
166
167
+
`CheckAsync` evaluates whether the current authenticated user is authorized to perform a specific action against a resource.
168
+
169
+
It provides an **on-demand, server-side authorization decision** based on the current authentication context, permissions, roles, and applicable authorization policies.
170
+
171
+
Unlike operations that perform protected actions, `CheckAsync` only evaluates access. It does not execute the requested operation, modify permissions, grant access, or reserve authorization for a future request.
172
+
173
+
### When to Use CheckAsync
174
+
175
+
Use `CheckAsync` when your application needs to:
176
+
177
+
- Determine whether an authenticated user can perform an action before presenting it in the UI.
178
+
- Enable, disable, or hide controls based on the current authorization decision.
179
+
- Explain why an operation is unavailable, using the returned denial reason where appropriate.
180
+
- Determine whether an operation requires reauthentication.
181
+
- Evaluate resource-specific access when the applicable policies support it.
182
+
183
+
For example, an application may check whether the current user can delete a particular order before displaying the Delete button.
184
+
185
+
### What CheckAsync Does Not Guarantee
186
+
187
+
**A successful authorization check is not a guarantee that a subsequent operation will succeed.**
188
+
189
+
Authorization is evaluated against the security context available at the time of the check. That context may change before the actual operation is performed.
190
+
191
+
For example:
192
+
193
+
- An administrator may revoke the user's permissions.
194
+
- The user's session may expire or become invalid.
195
+
- The target resource may be deleted or modified.
196
+
- The resource's ownership or tenant context may change.
197
+
- Additional business rules may prevent the operation.
198
+
199
+
The protected operation must independently enforce authorization using its current context.
200
+
201
+
**Never use a previous `CheckAsync` result as proof of authorization for a later request.**
202
+
203
+
`CheckAsync` is primarily a developer-experience and user-experience API. It helps applications understand and present authorization decisions without replacing the security enforcement performed by protected endpoints and application services.
204
+
167
205
Use `CheckAsync` to ask the server whether the current user is authorized to perform an action.
168
206
169
207
```csharp
@@ -230,6 +268,46 @@ Do not assume that sending `ResourceId` automatically enables ownership checking
230
268
|`RequiresReauthentication`| Whether the decision indicates reauthentication is required |
231
269
|`DenyReason`| Optional denial reason code |
232
270
271
+
### Authorization Decisions vs. HTTP Results
272
+
273
+
`CheckAsync` separates the outcome of the API request from the authorization decision itself.
274
+
275
+
The method returns `UAuthResult<AuthorizationResult>`:
276
+
277
+
-`UAuthResult.IsSuccess` indicates whether the authorization check request completed successfully.
278
+
-`AuthorizationResult.IsAllowed` indicates whether the requested action is currently authorized.
279
+
-`AuthorizationResult.RequiresReauthentication` indicates whether additional authentication is required.
280
+
-`AuthorizationResult.DenyReason` provides an optional reason for denial.
281
+
282
+
A denied authorization decision is a valid result of a successful authorization check.
| Caller not authenticated |`401 Unauthorized`| No authorization decision |
290
+
| Invalid request |`400 Bad Request`| No authorization decision |
291
+
| Server-side evaluation failure | Appropriate error status | No authorization decision |
292
+
293
+
**HTTP 200 means the authorization evaluation completed successfully. It does not mean access was granted.**
294
+
295
+
Only authenticated callers can use the current `CheckAsync` endpoint. However, callers do not need permission to perform the action they are checking.
296
+
297
+
This distinction is intentional: the purpose of `CheckAsync` is to determine whether the action is permitted.
298
+
299
+
### Handling Denied Decisions
300
+
301
+
Applications should distinguish between authorization denial, reauthentication requirements, and request failures.
302
+
303
+
A denied decision may be used to disable an action or display an appropriate message.
304
+
305
+
A reauthentication requirement may be used to initiate the application's supported reauthentication flow.
306
+
307
+
A failed request must not be interpreted as permission to proceed.
308
+
309
+
**Fail closed:** If the authorization decision is unavailable, treat the operation as unavailable in the UI and rely on server-side authorization when the actual operation is requested.
Copy file name to clipboardExpand all lines: docs/content/how-to-guides/protect-a-page.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -739,6 +739,8 @@ That endpoint must independently validate the caller and enforce the required au
739
739
740
740
For Blazor Server, the same principle applies to sensitive server-side operations, even when they are invoked without an HTTP call from the component.
741
741
742
+
> Use [UAuthAuthorize] to declare authorization requirements for routed pages and UAuthStateView for conditional UI rendering. Use UAuthClient.Authorization.CheckAsync() when you need an explicit, on-demand server-side authorization decision for a specific action or resource. These mechanisms serve different purposes and do not replace authorization enforcement on protected server operations.
743
+
742
744
### UAuthAuthorize is currently a Blazor attribute
743
745
744
746
The current `[UAuthAuthorize]` attribute is interpreted by UltimateAuth's Blazor authorization pipeline.
Copy file name to clipboardExpand all lines: docs/website/CodeBeam.UltimateAuth.Docs.Wasm/CodeBeam.UltimateAuth.Docs.Wasm.Client/wwwroot/docs/client-sdk/authorization.json
Copy file name to clipboardExpand all lines: docs/website/CodeBeam.UltimateAuth.Docs.Wasm/CodeBeam.UltimateAuth.Docs.Wasm.Client/wwwroot/docs/how-to-guides/protect-a-page.json
0 commit comments