# Authentication An authentication system determines the identity of a user or agent and the level of trust associated with this identity. For authentication, the ESS [Solid OIDC Broker Service](https://docs.inrupt.com/ess/latest/services/service-oidc/) implements the [Solid-OIDC](https://solid.github.io/solid-oidc/) specification. [Solid-OIDC](https://solid.github.io/solid-oidc/) specification builds upon the [OpenID Connect](https://openid.net/connect/) (OIDC) standards, which itself builds on the [OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) authorization framework. * [OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) defines a framework for authorization, in which a client obtains an access token to obtain access to resources. * [OpenID Connect](https://openid.net/connect/) defines a standard mechanism by which a web application leads a user through a login flow. The login flow results in a signed ID token, which is a [JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519) (JWT) that asserts the identity of the user.\ Since [OpenID Connect](https://openid.net/connect/) builds on the [OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) framework, [OpenID Connect](https://openid.net/connect/) flow produces both access tokens and ID tokens. As the token names suggest, access tokens are generally used to gain access to resources whereas ID tokens are used to identify a user. ## Identity ### WebID Rather than representing the identity of users with any string (e.g., **`user1234`** , etc.), Solid identifies users with a [WebID](/reference/glossary.md#webid). A WebID is a URL (e.g., **`https://id..com/user1234`** ) that can be dereferenced to an RDF profile document. ESS includes a [WebID Service](https://docs.inrupt.com/ess/latest/services/service-webid/). WebIDs issued by ESS have the form: ```none https://id./ ``` ### Client Identifier (Client ID) In [Solid-OIDC](https://solid.github.io/solid-oidc/), an application identifies itself using a [client identifier (Client ID)](/reference/glossary.md#client-id). A Client ID can be: * a URL that dereferences to a [Client ID Document](https://solid.github.io/solid-oidc/#clientids-document). * a value that has been registered using either [OIDC dynamic or static registration](https://solid.github.io/solid-oidc/#clientids-oidc). #### **Solid-OIDC Client ID Document** ESS supports [Client Identifiers (Client IDs)](https://solid.github.io/solid-oidc/#clientids) that are of type URL and dereference to a JSON-LD document, the [Client ID Document](https://solid.github.io/solid-oidc/#clientids-document) . #### **Client Registration** For applications that do not use identifiers that dereference to a Client ID Document, they can [register](https://datatracker.ietf.org/doc/html/rfc7591.html) with ESS’ [Solid OIDC Broker service (the Broker)](https://docs.inrupt.com/ess/latest/services/service-oidc/) . To register, a client provides various [metadata about itself](https://datatracker.ietf.org/doc/html/rfc7591#section-2) as part of its registration request (see [RFC7591: 3.1 Client Registration Request](https://www.rfc-editor.org/rfc/rfc7591#section-3.1)). Upon successful registration, the Broker responds with a unique **`client_id`** . The response may include additional fields. For details, see [RFC7591: 3.2 Client Registration Responses](https://www.rfc-editor.org/rfc/rfc7591#section-3.2) . #### **Dynamic Registration** To dynamically register an application, an application POSTs to [the Broker’s](https://docs.inrupt.com/ess/latest/services/service-oidc/) client **`registration_endpoint`** with the client’s metadata. {% hint style="info" %} Tip\ To determine if the Broker supports dynamic client registration, check its **`/.well-known/openid-configuration`** for the **`registration_endpoint`** field. {% endhint %} Inrupt’s JavaScript client libraries provide **`login`** APIs that handle dynamic registration of applications. #### **Static Registration** ESS supports [static registration of client applications](/ess/latest/services/service-oidc/service-application-registration.md) associated with a user (i.e., WebID). Static registration results in client credentials (i.e., **`client_id`** and **`client_secret`** ). ESS’ application registration returns **`client_id`** of type UUID. Single-user scripts and bots can use these client credentials to authenticate (on behalf of the user) without requiring browser-based user interactions with the Identity Provider. For details, see [Application Registration](/ess/latest/services/service-oidc/service-application-registration.md). ### **Client IDs in Allow Lists and Access Policies** ESS supports the use of Client IDs in client allow list configurations and access policies to specify which clients can be used. For details, see [Authorization and Clients](/security/authorization.md#authorization-and-clients). ## Tokens As part of the ESS login flow, which implements the [Solid-OIDC](https://solid.github.io/solid-oidc/) specification, ESS’ [Solid OIDC Broker Service](https://docs.inrupt.com/ess/latest/services/service-oidc/) issues ID tokens and access tokens. The [Solid OIDC Broker Service](https://docs.inrupt.com/ess/latest/services/service-oidc/) includes the WebID and the Client ID as claims in these tokens. ### **ID Tokens** An ID token asserts the identity of the user and is represented as a [JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519) (JWT). #### **ID Token Structure** The [OpenID specification](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) defines an extensible data structure for ID Tokens. This data structure is serialized as a [JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519). See also [Broker Token Claims](https://docs.inrupt.com/ess/latest/services/service-oidc/#openidp-claims). #### **Lifespan** ESS ID tokens have a default lifespan of 5 minutes (see [**`SMALLRYE_JWT_NEW_TOKEN_LIFESPAN`**](https://docs.inrupt.com/ess/latest/services/service-oidc#smallrye_jwt_new_token_lifespan)). ### **Signed Access Token** The ESS login flow results in signed access tokens. Access tokens provide access to resources. An access token issued by ESS is represented as a [JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519) (JWT). ESS verifies the token signature and that the token has not expired. An invalid token cannot be used to gain access to resources. #### **Signed Access Token Structure** ESS uses the JWT-based structure for access tokens. See also [Broker Token Claims](https://docs.inrupt.com/ess/latest/services/service-oidc/#openidp-claims). #### **Lifespan** ESS access tokens have a default lifespan of 5 minutes (see [**`SMALLRYE_JWT_NEW_TOKEN_LIFESPAN`**](https://docs.inrupt.com/ess/latest/services/service-oidc#smallrye_jwt_new_token_lifespan)). #### **Demonstration of Proof-of-Possession (DPoP) Token** As an additional layer of protection against token stealing and various replay attacks, Solid clients can send an additional HTTP header (specifically a [DPoP proof](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-00)). A [DPoP proof](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-00) can be used to verify that a client is in legitimate possession of an access token while also scoping the request to a particular Pod resource. This helps prevent against token exfiltration attacks. ESS uses version 00 of DPoP. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.inrupt.com/security/authentication.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.