From 1a4ffc7f3a2421026d42107a045b18288962e59b Mon Sep 17 00:00:00 2001 From: Roland Guijt Date: Wed, 14 Aug 2024 11:50:33 +0200 Subject: [PATCH] Eleborate on claims dependant on context --- .../v7/docs/content/reference/services/profile_service.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/IdentityServer/v7/docs/content/reference/services/profile_service.md b/IdentityServer/v7/docs/content/reference/services/profile_service.md index b5b9b016..358f8ca9 100644 --- a/IdentityServer/v7/docs/content/reference/services/profile_service.md +++ b/IdentityServer/v7/docs/content/reference/services/profile_service.md @@ -45,9 +45,12 @@ Models the request for user claims and is the vehicle to return those claims. It * ***Subject*** - The *ClaimsPrincipal* modeling the user associated with this request for profile data. When the profile service is invoked for tokens, the *Subject* property will contain the principal that was issued during user sign-in. When the profile service is called for requests to the [userinfo endpoint]({{< ref "/reference/endpoints/userinfo" >}}), the *Subject* property will contain a claims principal populated with the claims in the access token used to authorize the userinfo call. + The *ClaimsPrincipal* modeling the user associated with this request for profile data. When the profile service is invoked for tokens, the *Subject* property will contain the user's principal. Which claims are contained in the principal depends on the following: - When the [server side sessions feature]({{< ref "ui/server_side_sessions/" >}}) is enabled _Subject_ will always contain the claims in the session. + - When the [server side sessions feature]({{< ref "ui/server_side_sessions/" >}}) is enabled _Subject_ will always contain the claims stored in the server side session. + - When that is not the case, it depends on the caller context: + - If the _ProfileService_ is called in the context of grant (e.g. exchanging a code for a token) the claims stored in the grant store will be used. + - If there's no grant context (e.g. when the user info endpoint is called) the claims in the access token will be used. * ***Client***