An authentication system determines the identity of a user or agent and the level of trust associated with this identity.

OpenID Connect (OIDC) defines a standard mechanism by which a web application leads a user through a login flow. The flow results in a signed JSON web token (JWT) that asserts the identity of the user.



Solid builds on the OpenID Connect specificiations. Rather than representing the identity of a user with any string (e.g., user1234), Solid identifies users with a URL that can be dereferenced as a WebID profile (e.g., The WebID profile resource makes claims about trusted identity providers that can legitimately issue signed JSON web token on behalf of this WebID.

Client Identifier#

Starting in version 1.1, Inrupt’s Enterprise Solid Server (ESS) supports, as a Beta feature, the authentication of client applications. This Beta feature allows you to decide not only who has access to your data, but also which applications are used to access your data. For more information on using Inrupt’s JavaScript client libraries for authenticating client applications, including a sample client identifier document, see Authenticate Client Applications.

For more information, see Solid-OIDC specification: Client Identifiers.

Signed Access Token#

Central to this trust model is the signed JSON web token. A Pod server can verify that the token signature is legitimate by using a well-defined protocol that is part of the OIDC specification. If the signature is not valid or if the token has expired, a client will be denied access to a Pod.

Demonstration of Proof-of-Possession (DPoP) Token#

As an additional layer of protection against token stealing and various replay attacks, Solid clients send an additional token (specifically a DPoP token) that cryptographically proves that the client is in legitimate possession of the access token while also scoping the request to a particular Pod resource. This helps prevent against token exfiltration attacks.

For more information, see Solid-OIDC specification.