IdentityProvider service
IIdentityProvider serves identity presentation data during HTTP requests. It always derives the identity from the authenticated principal of the current request and the details your IProvideIdentityDetails returns for it. Nothing else the client sends, such as the .cratis-identity cookie earlier versions wrote, is read. The result is still presentation data: it is not authorization evidence on its own.
Key methods
Section titled “Key methods”| Method | Behavior |
|---|---|
Get() | Builds a result from the current request principal and details provider. With no request context, or no authenticated principal, returns anonymous. |
Get<TDetails>() | Uses the same flow and converts the details to TDetails. |
SetCookieForHttpResponse(result) | Writes the result as the JSON response body, with Cache-Control: no-store, private and Vary: Cookie. Despite its name, it no longer writes a cookie; it expires a .cratis-identity cookie left by an earlier version. It does not establish a trusted principal. |
ModifyDetails<TDetails>(transform) | Calls nongeneric Get(), applies the transform when Details is TDetails, and writes the modified result to the response; otherwise does nothing. |
The identity comes from the authenticated principal, so a client cannot change what Get() returns without changing its credentials. The details provider runs on every call; cache expensive lookups inside it if you need to.
Never use the result’s IsAuthenticated, IsAuthorized, roles, or details in place of authorization. Read ICurrentPrincipalAccessor.Current from Cratis.Arc.Authorization and authoritative application data, and protect commands and queries with pipeline authorization. The result is sent to the browser, so avoid putting secrets or unnecessary personal data in the details.
Modifying details
Section titled “Modifying details”ModifyDetails<TDetails>(...) changes what the current response reports. It does not store anything: the next request derives the identity from the principal again. Persist durable preferences through an authenticated application operation and authoritative storage, and return them from your details provider.
ModifyDetails writes the JSON response itself; do not write another response body after calling it.
Upgrading from the identity cookie
Section titled “Upgrading from the identity cookie”Earlier versions returned whatever the unsigned .cratis-identity cookie decoded to before looking at the authenticated principal, and wrote that cookie readable by any script. Arc no longer trusts or writes it. See migrating from the identity cookie for what keeps working during the transition and what to change.
Related contracts
Section titled “Related contracts”- Migrating from the identity cookie
- Provider flow — how a request becomes an identity.
- Authorization — trusted principal and pipeline enforcement.
- Frontend identity — presenting identity details.