An authentication system determines the identity of a user or agent and the level of trust associated with this identity.
For authentication, the ESS OpenID Provider implements the Solid-OIDC specification. Solid-OIDC specification builds upon the OpenID Connect standards, which itself builds on the OAuth 2.0 authorization framework.
OAuth 2.0 defines a framework for authorization, in which a client obtains an access token to obtain access to resources.
OpenID 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 (JWT) that asserts the identity of the user.
Since OpenID Connect builds on the OAuth 2.0 framework, OpenID 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.
Rather than representing the identity of users
with any string (e.g.,
user1234, etc.), Solid
identifies users with a WebID. A WebID is a URL (e.g.,
https://id.<ESS Domain>.com/user1234) that can be
dereferenced to an RDF profile document.
ESS includes a WebID Service. WebIDs issued by ESS have the form:
Clients (or applications) register with ESS’ OpenID Provider before they can log in users with OpenID Connect or request OAuth 2.0 access tokens. To register, a client provides various metadata about itself as part of its registration request (see RFC7591: 3.1 Client Registration Request).
Upon successful registration, the OpenID Provider responds with a
client_id. The response may include additional fields. For details,
see RFC7591: 3.2 Client Registration Responses.
To dynamically register an application POSTs to
OpenID Provider’s client
registration_endpoint with the client’s metadata.
To determine if OpenID Provider supports dynamic client
registration, check its
/.well-known/openid-configuration for the
login APIs that handle
dynamic registration of applications.
Solid-OIDC Client ID Registration#
Solid-OIDC, and Inrupt’s Enterprise Solid Server (ESS), supports the registration of client applications via Client Identifiers (Client IDs). A Client ID, is a URL that can be dereferenced to a JSON-LD document that contains the application’s metadata.
Allow List of Client IDs#
In ESS, the use of Client IDs (URLs) also allows you to decide not only who has access to your data but also which applications are used to access your data.
For example, to specify which applications can modify the Access
Control Resource (i.e., applications that can modify the Access Control
Policies for Pod resources), operators can set
INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST to Client IDs (URLs) of the
allowed applications. This list can also be used to initialize a Pod
Resource’s access policies.
ESS supports static registration of client applications associated with a user
(i.e., WebID). Static registration results in client credentials (i.e.,
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.
An ID token asserts the identity of the user and is represented as a JSON Web Token (JWT).
ID Token Structure#
See also OpenID Provider Token Claims.
ESS ID tokens have a default lifespan of 5 minutes (see
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 (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 OpenID Provider Token Claims.
ESS access tokens have a default lifespan of 5 minutes (see
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).
A DPoP proof 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.