Authentication

Authenticating with the LearnCard Network API

To interact with the LearnCard Network API, you can choose one of two ways to authenticate:

  1. Using the LearnCard Network Plugin (@learncard/network-plugin) which handles authentication for you. (Preferred option)

  2. Using a scoped API Token for authentication with API endpoints. (recommended for implementations using REST endpoints).

  3. Directly through the API endpoints using challenge-based DID Authentication. (most complex)

1. Using LearnCard Network Plugin

To authenticate using the LearnCard Network Plugin (@learncard/network-plugin), first install the package:

pnpm install @learncard/network-plugin

Then, either instantiate a LearnCard Network enabled LearnCard, or add the Network Plugin to an existing LearnCard:

import { initLearnCard } from '@learncard/init';
import didkit from '@learncard/didkit-plugin/dist/didkit/didkit_wasm_bg.wasm?url';

const networkLearnCard = await initLearnCard({
    seed,
    network: true,
    didkit,
});

When using the LearnCard Network Plugin, challenge-based DID Authentication is handled for you, so no further steps are necessary.

2. Using a scoped API Token

3. Using Challenge-based DID Authentication

Profile management uses DID-based authentication with a challenge-response mechanism and scope-based authorization.

Simple High-Level Auth Flow:

Granular Auth Flow:

If you choose to use the API endpoints directly, you'll need to manage challenge-based DID Authentication for each request. Here's a simplified TypeScript example to help you implement this authentication method:

In this example, we first define a getClient function that takes a url and a didAuthFunction. The didAuthFunction should be an asynchronous function that returns a signed challenge as a string.

The getChallenges function fetches a list of challenges from the API. The getAuthHeaders function generates an Authorization header using the didAuthFunction and a challenge. This header can then be used in your API calls.

Authorization & Scopes

Route Middleware

The system uses several middleware layers for authentication and authorization:

  1. openRoute: Base middleware that allows public access

  2. didRoute: Requires a valid DID in the request

  3. didAndChallengeRoute: Requires a valid DID and challenge

  4. profileRoute: Requires a valid DID, challenge, and existing profile

  5. scopedRoute: Requires specific permission scopes

Authorization Scopes

Each API endpoint requires specific scopes for authorization:

Scope
Description
Example Endpoints

profiles:read

Read profile information

getProfile, getOtherProfile

profiles:write

Create or update profiles

createProfile, updateProfile

profiles:delete

Delete profiles

deleteProfile

connections:read

View connections

paginatedConnections

connections:write

Manage connections

connectWith, blockProfile

signingAuthorities:read

View signing authorities

signingAuthorities

signingAuthorities:write

Manage signing authorities

registerSigningAuthority

The authorization system also supports wildcard scopes like *:read (read access to all resources) and *:* (full access).

Last updated

Was this helpful?