# 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](https://docs.inrupt.com/reference/glossary#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)](https://docs.inrupt.com/reference/glossary#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](https://docs.inrupt.com/ess/latest/services/service-oidc/service-application-registration) 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](https://docs.inrupt.com/ess/latest/services/service-oidc/service-application-registration). ### **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](https://docs.inrupt.com/authorization#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.